<rqou>
also azonenberg: it's really really cool how ethernet scales from 10mbit to 400gbit
Bike has quit [Quit: Lost terminal]
<qu1j0t3>
CSMA/CD did not.
<qu1j0t3>
it required a radical change in topology to scale past ... 10-100
<qu1j0t3>
radical and expensive for the time)
<sorear>
The successor to Ethernet will be called Ethernet.
<qu1j0t3>
yes, the successor to 10B2 was also called Ethernet :)
<qu1j0t3>
the name masks some major changes.
xdeller_ has joined ##openfpga
xdeller has quit [Remote host closed the connection]
<awygle>
we have always been at war with 25GBASE-FR
<qu1j0t3>
:)
noobineer has joined ##openfpga
noobineer has quit [Ping timeout: 260 seconds]
<whitequark>
rqou: quite well
<whitequark>
what about it
digshadow has quit [Ping timeout: 256 seconds]
<rqou>
i _might_ (just might, not definitely) be able to help them with their new problem, but i tend to filter requests for help with the heuristic of "does anybody i already know/trust know/trust them?"
<rqou>
(i saw the RT from bofh)
<sorear>
I know her not-as-well for a long time
<rqou>
hmm yeah unfortunately maybe not :(
<rqou>
nevermind
<openfpga-github>
[libfx2] whitequark closed pull request #1: Support IHEX record type 0x04 in `input_data`. (master...ihex-type4) https://github.com/whitequark/libfx2/pull/1
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<rqou>
huh i just found out about C++/CX
<rqou>
azonenberg: did you know Microsoft made yet another weird C++ extension?
<rqou>
also have you seen it in client code? :P
<kc8apf>
So, xc7 configuration frames are in a non-contiguous memory space similar to a PCI config space window.
<kc8apf>
the addressing is fixed for the whole series but the valid ranges are per-device
<kc8apf>
what's a good way to encode this in a data file?
<rqou>
a switch statement? :P
<kc8apf>
it's a bunch of small address windows (10-30 addresses in a contiguous block)
<rqou>
azonenberg seems to be of the opinion that "data files" are a bad idea
<kc8apf>
I'd rather not create a switch statement for _every_ device in the xc7 family
<kc8apf>
it'd only be per-die but that's still a lot of variants now
<rqou>
my code has all of this encoded into switch statements
<kc8apf>
for how many devices?
<rqou>
only 7
<rqou>
er, 8
<rqou>
but my though was that you need the same amount of data no matter what, and mmap-ing a lookup table is probably faster than parsing a data file
<rqou>
so might as well force the compiler to do the parsing
<kc8apf>
I'm seeing 32 xc7 variants. Just generating these is gonna take a while.
<rqou>
but you need to do that anyways
<kc8apf>
hmmm. Well, the frame minor address seems to be the only contiguous section. If I assume that, I can use a frame address and minor frame count.
<kc8apf>
then it's just a long list of thoise
<azonenberg>
kc8apf: yeah that makes sense
<azonenberg>
qu1j0t3: it's funny that the 40Gbase-R section of 802.3 is still titled CSMA/CD lol
<rqou>
wtf?
<azonenberg>
rqou: the title of the document never changed
<azonenberg>
since 10BASE-T
<azonenberg>
rqou: also re data files
<azonenberg>
i was actually thinking of going with a data-driven approach for some greenpak stuff, but it would be compile-time code generation
<azonenberg>
So you could do things like derive from an auto-generated class to special case handling of some attribute
<azonenberg>
I havent had time to think about the implementation in any detail whatsoever though
<azonenberg>
qu1j0t3: the main thing i like about ethernet is that the same layer 2 scales so far
<azonenberg>
you can bridge a 10 baseT/half endpoint to a 100GBASE-* core router if you have the right stuff in between
<kc8apf>
I need to read up on greenpak internals
<azonenberg>
i need to find time to work on it more
<azonenberg>
:p
<azonenberg>
i want to add suport for more chips
<azonenberg>
if i sit down and refactor a bunch, it should be fairly easy
<azonenberg>
the current architecture works but is a pain in teh butt to extend
<rqou>
lol i noticed :P
<azonenberg>
in other news, the hole in the wall where my HVAC return duct will eventually live
<kc8apf>
I want to implement a few different architectures in gaffe to get a better feel for what the IR just above the series-specific IRs should be
<azonenberg>
is now framed out :p
<azonenberg>
kc8apf: so, greenpak is a bit of a unique architecture for several reasons
<azonenberg>
the routing topology is a CPLD-style crossbar but the logic elements are LUTs
<kc8apf>
that's why I want to look at it more
<azonenberg>
(there's no 2D tiles)
<azonenberg>
the bitstream is ascii text, one bit per line
<azonenberg>
maaaaaassively bloated
<kc8apf>
wtf?
<azonenberg>
Yes
<azonenberg>
the basic format is
<azonenberg>
bit number (decimal ascii)
<azonenberg>
whitespace
<azonenberg>
bit value, ascii '0' or '1'
<azonenberg>
optional whitespace, //, comment
<azonenberg>
newline
<azonenberg>
rinse and repeat
<rqou>
lolol
<rqou>
meanwhile xc2bit has two data formats
<rqou>
.jed, and native
<azonenberg>
you thought JED was bad with ascii 0/1s and block-based addressing...
<kc8apf>
I'm going to write good tools so these clowns will stop inventing even worse ways to program these devices
<rqou>
oh, native is still ascii
<rqou>
for xc2bit
<azonenberg>
kc8apf: btw is gaffe c++?
<azonenberg>
i havent looked at it
<kc8apf>
rust
<rqou>
it's a 2d grid of '1'/'0'
<azonenberg>
kc8apf: :( oh well
<rqou>
rust is way more powerful
<rqou>
e.g. the other day when i ported xc2bit to use magic procedural macros
<rqou>
it removed a decent amount of error-prone copypasta
<kc8apf>
I love C++ but plugin-like models are a pain to create there
<azonenberg>
$client bought it for me, technically - pretty sure i have to give it back eventually
<azonenberg>
Although i may try and negotiate it as part of my compensation
<rqou>
meh they're not _that_ expensive
<azonenberg>
rqou: the 192GB of RAM and dual socket xeons are
<rqou>
~$1k order of magnitude
<azonenberg>
:p
<azonenberg>
This is primarily a "build fpga designs for a huge virtex" workstation
<rqou>
oh the client loaned you an entire workstation?
<azonenberg>
it just happens to also be the thing i talk to said virtex with
<azonenberg>
Designed to my spec and drop-shipped to me
<azonenberg>
it didnt come out of their inventory
<azonenberg>
But yeah
<azonenberg>
I used 40GB of ram on one build recently
<azonenberg>
Wasn't gonna happen with the 32G i had on my personal box
<rqou>
hmm wait is this the exact same case i have? :P
<rqou>
random cheap case with an acrylic panel?
<azonenberg>
Dont know, i didnt pay attention to the case
<azonenberg>
i cared about the guts
<rqou>
lol same
<awygle>
azonenberg: remind me, when you complain about the checksum being in the wrong place for cut-through switching - that's the IP checksum, right? if you're doing pure ethernet swtiching it's not a problem?
<azonenberg>
Actually it's udp and tcp
<azonenberg>
the ethernet checksum is in a sane place, at the end of the frame
<azonenberg>
i.e. as soon as you have the data, you have the checksum
<azonenberg>
and you can send data and compute the checksum on the fly, then send the checksum
<awygle>
right, ok
<azonenberg>
IP has a checksum at the end of the IP header
<azonenberg>
but it only covers the IP header
<awygle>
ah yeah i remember now
<azonenberg>
i think you might have to buffer 32 or 64 bits but no big deal
* awygle
could have looked this up but... lazy
<azonenberg>
TCP and UDP have a checksum in the header that covers the packet content
bitd has joined ##openfpga
<azonenberg>
you cannot compute that until the packet content is already there
<azonenberg>
It's not an issue for layer 2
<azonenberg>
But at the endpoint, you cannot send a tcp segment out onto the wire until the content is known
<azonenberg>
vs at layer 2 you can begin sending a frame blind and generate it as you go
<azonenberg>
then have a valid crc at the end
<rqou>
is there an "ignore checksum" option?
<rqou>
iirc udp has one
<azonenberg>
for tcp. no
<azonenberg>
for udp over ipv4, yes
<azonenberg>
for udp over ipv6, no
<rqou>
wat
<azonenberg>
in ipv6 the udp checksum is mandatory
<azonenberg>
in ipv4, setting it to zero disables checksumming
<rqou>
it's amazing that this all works despite all of this confusing terminology
<rqou>
also "The SFP transceiver is not standardized by any official standards body, but rather is specified by a multi-source agreement (MSA) among competing manufacturers."
<azonenberg>
So it looks like XFP does clock recovery and retiming in the optic
<azonenberg>
while SFP just buffers
<rqou>
so somehow everybody managed to magically agree on how to do things
<awygle>
well, in the module. presumably it does it in electrical land
<azonenberg>
awygle: when i say "the optic" in networking i mean the module
<azonenberg>
not literally the optical subsystem
<awygle>
sloppy :p
<azonenberg>
But i think the module still has stuff like AGC etc
<rqou>
yes
<azonenberg>
unless you buy a linear one (rare)
<azonenberg>
Which doesnt do any signal conditioning at all
<rqou>
which is why shitty "AV" tech needs special SFPs for SDI
<azonenberg>
and can plausibly used for a DIY OTDR
<azonenberg>
should i be so inclined one day... :p
<rqou>
because SDI is a shitty protocol with a shitty scrambler
<rqou>
which can confuse normal "networking" SFPs
<rqou>
azonenberg: and you thought 100base-t was bad :P
<azonenberg>
Hmmm
<azonenberg>
So apparently bel fuse does not publish a step model for this rj45 module i'm using
<azonenberg>
and nobody else seems to make halfway decent 2x4 rj45s with leds
<azonenberg>
this is going to be slightly terrifying
<azonenberg>
I might order a dummy 2-layer oshpark or even hackvana board with the footprint on it
<azonenberg>
to fit test :p
<awygle>
step models are for cowards
<awygle>
#FIFI #YOLO
<awygle>
is there _anything_ that uses more of a 16 Gb transceiver than 10 GbE?
<rqou>
fibre channel?
<awygle>
there must be something
<azonenberg>
yeah xilinx has 16G transceivers on a bunch of stuff
<azonenberg>
idk what i'd use it for
<awygle>
rqou gets the prize
<azonenberg>
i need 10.3125
<azonenberg>
:p
<awygle>
apparently fibre channel has like a 14ish gpbs standard
<rqou>
a lot of the modern ethernet stuff is actually stolen from FC
<rqou>
or possibly SONET sometimes
<awygle>
actually it's weird because it's 14ish line rate but 16 GB/s data rate? must be multiple lines
<awygle>
i should build my proposed FPGA-based NIC and sell it to HFT companies
<azonenberg>
Good luck standing out from the crowd
<azonenberg>
there's a lot of those
<awygle>
there are indeed
<awygle>
that's what i learned today that prompted the comment
<awygle>
networking is very cool
<rqou>
whee, time to GC calcs and browser tabs
<rqou>
because the browser is now hitting OOM almost instantly after relaunch
<awygle>
okay, i give up. there's no bug in this code. this code is perfect.
<azonenberg>
rqou: you dont have a browser that lazily loads tabs?
<rqou>
not enough
<azonenberg>
how do you think i have circa 300 tabs in each firefox window?
<rqou>
the master process eventually OOMs
<azonenberg>
i kill it, then load tabs as i go
<azonenberg>
I do GC periodically, but not often enough
<awygle>
i'll take "by having 128GB of RAM" for 500$, Alex
<rqou>
the master process currently has 5GB resident
<rqou>
and i put the browser in an 8GB cgroup because otherwise the whole system tended to freeze as ram got scarce
<azonenberg>
awygle: i wish 128G of RAM was $500
<azonenberg>
:p
<azonenberg>
and i have my browsers in VMs with 2-4 GB each
<awygle>
my firefoxes don't seem to actually eat that much RAM, but they do start lagging over time for no discernable rason
<azonenberg>
Mine too
<azonenberg>
with 100% cpu load
<rqou>
actually you know what? tab bankruptcy time
<azonenberg>
So i kill them and restart periodically, and also gc tabs as i go
<awygle>
i wonder if inbox is the problem, as i tend to have that open all the time
<rqou>
twitter is definitely a huge offender
<awygle>
twitter is phone-only
<awygle>
for me
<azonenberg>
i dont trust social media on a phone
<azonenberg>
The apps have way too many permissions
<azonenberg>
with a browser i can sandbox it off a bit in a vm
<azonenberg>
it cant see my browsing in other vms, etc
<awygle>
eh, everything's fucked anyway
<azonenberg>
yeah but might as well make them work for it
<awygle>
i've basically declared privacy bankruptcy except on, like, bank accounts
<azonenberg>
Those live in another vm :p
<awygle>
all right, time to try to sleep despite being on hour 4 of my 5 hour energy
<awygle>
goodnight all
<rqou>
what the hell
<rqou>
octave doesn't have c2d/lqrd/any actualy useful functions
<rqou>
i just wanted something to check my work against goddammit
<rqou>
i'll check against matlab later since that requires a windoze box
<rqou>
also, is it just me that finds A.dot(B) completely unreadable?
<azonenberg>
This is going to be a fun design to lay out :p
<whitequark>
doesnt look too bad
<rqou>
ugh
<rqou>
why is the arduino software 100MB?
<azonenberg>
maybe because they listened to your advice and statically linked everything? :P
<rqou>
nope
<rqou>
they listened to your(?) advice and used Java
<azonenberg>
not mine, lol
<rqou>
also 100MB isn't even all the stuff
<rqou>
just the AVR toolchain
<rqou>
this ecosystem is garbage
<rqou>
especially since i just installed the wrong thing
<rqou>
"Arduino SAM Boards" vs "Arduino SAMD Boards"
<rqou>
oh what
<rqou>
and it spews tons of bullshit on stdout while running
<rqou>
including raw mdns replies that it doesn't like for some reason
<rqou>
why is it even using mdns?
<rqou>
do i want to know?
m_w has joined ##openfpga
<rqou>
also arduino reinvented a package manager?
<felix_>
nice, a current kicad nightly build with the option to make it useable with touchpad on osx actually results in kicad being sort of useable on my laptop \o/ didn't expect that tbh...
<florolf>
whitequark: FWIW: i have no idea how businesses work over there, but jiepei.com seems to be equivalent to allpcb.com? i've seen the quotation interface cloned multiple times, so that's not much of an indicator, but https://www.jiepei.com/intro/contactus and http://www.allpcb.com/contact_us.html seem to be identical
<florolf>
the latter might be more accessible. not sure how much they make you pay extra for that, though
m_w has quit [Ping timeout: 268 seconds]
<rqou>
wow, sparkfun is so lame they can't even set +x bits correctly
<whitequark>
florolf: allpcb appears to be literally google translated jiepei
<whitequark>
rqou: what's the problem with it being 100MB
<rqou>
nothing, just seems bloated
<rqou>
oh, and baud rates are fucked up for some reason
<rqou>
i hate the arduino ecosystem
<rqou>
why does the Arduino ecosystem just feel like layers on top of layers of unclear-if-zero-cost abstractions that are either leaky or limited?
<whitequark>
because its only purpose is to hack shit together
<rqou>
i really want embedded-hal to get better
<rqou>
but EDEADLINE
<rqou>
Rustyduino when? :P
<cr1901_modern>
AFAIK, the AVR rust ppl aren't really following japaric's work anyway
<rqou>
hmm
<rqou>
what are they doing then?
<cr1901_modern>
unsafe around I/O last I checked :)
<rqou>
also, afaict "japaric's work" is unfortunately at this point in time "copypasta device crates and hal implementations a bajillion times" and "mess around with things that don't matter (like removing xargo)"
Bike has joined ##openfpga
<whitequark>
removing xargo?
<cr1901_modern>
embedded arm now uses cargo
<cr1901_modern>
i.e. it's truly "first class"
<whitequark>
yeah, how is that "doesn't matter"?
<rqou>
or "replacing the linker with lldb and losing major features along the way"
<rqou>
because xargo works?
<cr1901_modern>
rqou: B/c ppl are very sensitive to deviations
<rqou>
deviations?
<whitequark>
lld is the path forward
<whitequark>
if going to it means that some features need to be reimplemented, they'll have to be reimplemented
<rqou>
i wouldn't give up zero cost stack overflow protection just for lldb
<rqou>
er, i mean lld of course
<rqou>
although i did attempt to use lldb the other day and it was an intensely frustrating experience that I'm not interested in repeating again
<cr1901_modern>
>rqou: deviations
<cr1901_modern>
Nevermind, incomplete thought
<rqou>
basically in my experience the "llvm binutils equivalents" basically don't work
<whitequark>
rqou: then fix them
<whitequark>
that applies to lldb too
<whitequark>
submit a patch, tag me as a reviewer, etc
<rqou>
ENOTIME
<cr1901_modern>
You know that's a lot of work (and a lot of upfront learning).
<rqou>
gnu binutils works
<whitequark>
then stop whining
<rqou>
but other people waste time wishing the llvm binutils work
<rqou>
e.g. removing zero-cost stack overflow protection and gaining... nothing?
<whitequark>
llvm binutils have obvious advantages over gnu binutils and you know it
<rqou>
i really don't
<whitequark>
such as "not having to require everyone working on the project to get a gnu toolchain from somewhere"
<cr1901_modern>
License, and well afaik they aren't as horrifying internally (thirdhand)
<rqou>
i can see it for clang
<whitequark>
try getting that shit up on windows
<rqou>
i don't care about windows
<rqou>
use the devkitpro binutils or something
<whitequark>
i don't give a fuck whether you, personally, care about windows
<rqou>
they work fine on windows
<whitequark>
i give a fuck about the platform and the platform is better off with retargetable binutils
<whitequark>
if gnu pulls their head out of their ass and makes those, well, good
<whitequark>
but they aren't
<cr1901_modern>
retargetable binutils?
<whitequark>
cr1901_modern: one binary that handles any architecture
<whitequark>
also, that zero-cost stack overflow protection impl was a fucking abomination and i'm glad to see
<whitequark>
it gone
<rqou>
why?
<whitequark>
have you seen how it worked?
<rqou>
yeah, neat trick
<whitequark>
"neat trick"
<Bike>
how's it work?
<whitequark>
remind me to never use anything you write
X-Scale has quit [Ping timeout: 240 seconds]
<rqou>
ok, not having to link twice would be better
<q3k>
the stack probing thing?
<rqou>
no
<rqou>
it puts the stack at the beginning of ram and the heap and the end
<whitequark>
Bike: it replaced the linker with a wrapper that first linked the code, counted how large the code+heap were, then made a custom linker script and linked again
<rqou>
instead of the traditional heap at beginning and stack at end
<Bike>
o-oh
<whitequark>
it isn't portable too
<rqou>
what's wrong with this idea? other than "you aren't strictly guaranteed to crash"
<whitequark>
the fact that it's an overly complicated mess?
<rqou>
how?
<whitequark>
just fix your fucking linker to do it directly
<rqou>
oh, that part
<q3k>
i'd like if they made linker scripts turing complete so they could implement the secondary linker script emitting in the first linker script
<whitequark>
moreover
<whitequark>
it doesn't work on msp430, avr, or our or1k implementation
<q3k>
and by 'like' i mean 'scream internally for a few days straight'
<whitequark>
because they don't fault on out-of-address-space reads
<rqou>
sure
<rqou>
but if it works on a particular core, why not keep it?
<whitequark>
because it doesn't work with lld?
<rqou>
so don't use lld?
<cr1901_modern>
whitequark: Oh that. That reminds me- what happens if you feed clang and friends incompatible arch-specific/machine-specific opts (after choosing a target)?
<whitequark>
having a decent linker is more important than having this hack
<cr1901_modern>
(if you can*)
<whitequark>
the actual issue here is that rust doesn't know to do stack probing on architectures without MMU
<rqou>
but stack probes aren't zero cost
<whitequark>
so?
<rqou>
zero cost is better when possible?
<whitequark>
stack probes are a baseline requirement as a portable stack overflow prevention mechanism
<whitequark>
if you *can* make an optimization that makes it zero-cost, sure
<whitequark>
but you need a baseline mechanism anyway
X-Scale has joined ##openfpga
<rqou>
ok, i agree with that
<rqou>
but why would you remove the zero cost trick?
<whitequark>
I actually got the probe-stack attribute merged in LLVM
<whitequark>
rqou: because it doesn't work with lld?
<rqou>
imo that's just not a good enough reason
<whitequark>
having to install zero things apart from rust to do ARM development is important
<whitequark>
the fact that you don't understand it demonstrates that you don't have your priorities straight
<rqou>
i just don't see why is this so important? you only need a binutils, not a full gcc
<rqou>
also, exploring your goals, does this mean that rust should gain its own debugger and jtag/swd tool too?
<whitequark>
because by killing the binutils dependency you go from "find and install this weird crap which may or may not be packaged for your platform already and if yes may or may not be buggy and outdated" to "turnkey"
<whitequark>
I think rust is going to ship lldb eventually, yes
<rqou>
and openocd?
<whitequark>
jtag/swd tools are different, since they're bound to the hardware you're using and not the programming language
<whitequark>
openocd might not even work with your hardware, depending on what it is
<rqou>
also, like i mentioned, just grabbing a random linaro/devkitpro binutils works too
<whitequark>
not having to do it works much better
<q3k>
these days if you have a blackmagicprobe you can just use gdb/lldb/whatever to talk to it directly
<q3k>
bypassing the mess that is openocd
<whitequark>
most people still use shitty ft232 based boards
<q3k>
rqou: yes, but it's painful
<whitequark>
blackmagic is borderline unobtainium
<rqou>
i thought most people used stlink clones?
<q3k>
whitequark: how is it unobtainium?
<rqou>
unobtainium?
<q3k>
whitequark: send money, receive bmp
<whitequark>
q3k: i just remember their distributors carrying outdated versions, being sold out, etc
<whitequark>
took me a while to actually buy
<whitequark>
rqou: depends on the chip i guess
<whitequark>
if you're working with stm32 chances are you have an stlink somewhere
<rqou>
japaric's tutorials all assume stlinks
<q3k>
I think it's better now. I got it directly, from Germany.
<florolf>
huh, my process for getting a bmp is "get 1$ bluepill board and flash firmware"
<rqou>
lol
<whitequark>
ha, didn't realize you can do that
<q3k>
that too
<rqou>
that doesn't support the developers if you care about that and can currently afford that
<q3k>
i'm lazy and just wanted the thing working ootb
<florolf>
you won't get a nice connector from that, though
<whitequark>
^ yeah
<rqou>
but yes, I'm essentially doing that
<florolf>
rqou: yes, but see whitequark on unobtainium
<florolf>
whitequark: there's an official upstream target for that
<rqou>
DFU tends to be flaky though
<rqou>
at least if you're reflashing the stlink on a discovery
<florolf>
otoh, i usually use the segger stuff. if you don't need gdb, their tools are so much better
<whitequark>
better?!
<florolf>
ozone is actually a decent source-level debugger and has svd awareness
<florolf>
also, RTT is pretty cool, but it seems somebody is working on openocd support for that
<rqou>
anyways whitequark imo you can fix the binutils problem by just using musl-cross-make to build a set of statically-linked works-on-all-distros binutils (and punt the problem to devkitpro for windows)
<whitequark>
wtf
<q3k>
I use whatever is built into Segger Embedded Studio
<q3k>
and it's actually pretty neat
<whitequark>
this is exactly the kind of half-assed solutions rust should not have
<whitequark>
its excellent support for windows is one of the selling points, and you're compromising that
<rqou>
how is that half-assed?
<rqou>
I'm not
<q3k>
rqou: I'll be surprised if you can compile binutils statically against musl
<rqou>
devkitpro works perfectly on windows
<rqou>
q3k: er, it totally works?
<rqou>
musl-cross-make already knows how to do that
<whitequark>
or you could simply use llvm binutils that are already there and guaranteed to use the same backend as rust itself
<rqou>
how is it already there?
<q3k>
rqou: oh, it's built for that purpose
<whitequark>
they're built as part of llvm
noobineer has joined ##openfpga
<whitequark>
i remember how or1k binutils and or1k llvm diverged in some detail regarding DWARF and i wasted weeks figuring that out
<rqou>
wat
<rqou>
gg
<whitequark>
the or1k ld is buggy upstream too
<rqou>
huh
<whitequark>
I fixed one bug but never actually figured out the other
<rqou>
didn't know that
<whitequark>
the ld code is fucking *shit*
<rqou>
is it? I've always just assumed "works, whatever, not important"
<whitequark>
lol
<whitequark>
yes it is
<whitequark>
try actually reading it sometime
<q3k>
the binutils/gcc code is a dumpster fire
<whitequark>
i mean ld is just a shit linker in genreal too, it's slow as hell
<whitequark>
but that's not a big concern in embedded
<rqou>
hmm, there's multiple .y files so we're off to a great start (/s)
<q3k>
that's not the bad part
<whitequark>
as it is if you're porting rust to a new architecture you have to port llvm AND then you have to port binutils
<whitequark>
this is dumb
<rqou>
PE support has its own separate file, great abstraction there
<whitequark>
rqou: that part is actually kinda reasonable
<whitequark>
lld has three separate linkers inside
<whitequark>
pe, elf and macho
<whitequark>
they used to have one very abstract linker but it turned out that it didn't support any of the platforms well as a result and it got scrapped and rewritten
<Bike>
that's a pretty convoluted last paragraph in the license
<rqou>
huh, no longer that NCSA thing that nobody else really used
<rqou>
anyways i really need to zzz
pie_ has quit [Ping timeout: 240 seconds]
Bike is now known as Bicyclidine
* implr
joins rqou in arduino ecosystem hate
<implr>
I bought a stm32f7 discovery once. Really nice board, but... the chip is in a bga216 package, has basically infinity gpios. Want to connect them to something? ha ha fuck you, here's an arduino header
<q3k>
avnet pulls the same bullshit with zynq carrier boards
<q3k>
you get a handful of PMODs and an arduino header
rohitksingh_work has quit [Read error: Connection reset by peer]
<whitequark>
so
* whitequark
thinks
<whitequark>
can you make BGAs yourself?
<whitequark>
make a PCB with a BGA land pattern, "reball" it
<whitequark>
a BGA package has a PCB as its integral part, so it is definitely possible in theory
<q3k>
as long as you then manage to solder it without affecting the components on it, I think...
<q3k>
iirc you want to reflow the bga part, not the whatevers-on-that-bga-pseudo-thing part
<whitequark>
hm, good point, it'll have to reflow and whatever is on the top will impede that
<q3k>
unless you use some high-melt-point solder for that part, and low-melt-point for the bga
<q3k>
I think
<whitequark>
hmm
<q3k>
(also, here's a cool thing: depending on what I've been up to, my typing muscle memory either corrects bga to bgp or bgp to bga)
<jn__>
q3k: damn neural networks!
<q3k>
now I only need to use bgp for bga routing, or implement a bgp speaker on a bga fpga
<q3k>
for maximum brain confusion
<jn__>
obviously FBGA should be your package of choice for that project ;)
<whitequark>
lol q3p
<whitequark>
ERM
<whitequark>
Q3K
<q3k>
jn__: gah
<gruetzkopf>
i really dislike devboards that don't pull out every (or even most) unused IO pins
<G33KatWork>
while speaking of bga
<G33KatWork>
have an intel sbc here with obvious memory errors
<G33KatWork>
screen corruption, then something (I suspect TXE) turns off the board
<G33KatWork>
though to myself "can't break it any more, let's resolder the ram"
<G33KatWork>
fucked up, got a short somewhere
<G33KatWork>
pulled off all the chips, short gone
<G33KatWork>
now I need to reball 8 ddr3 chips and don't have a jig + stencils
<G33KatWork>
finished one by hand. not sure if I want to proceed that way :D
<G33KatWork>
and the coolest thing: I don't even know if a cold/broken joint was the initial problem
<G33KatWork>
¯\_(ツ)_/¯
<G33KatWork>
it felt like an adressing issue though
<G33KatWork>
TXE must have recognized something was messing with its memory contents or it crashed or whatever and it turned off the cpu
<G33KatWork>
only happened after writing after the first few megabytes of memory
<G33KatWork>
linux even booted. when writing to a tmpfs or doing a memtest though -> boom
<whitequark>
wtf reballing ddr3 by hand
<G33KatWork>
pulled that off sucessfully twice already
Bike has joined ##openfpga
<G33KatWork>
desoldered ddr3 chip(s) from board, traced the pinout using jtag boundary scan on a zynq, reballed and resoldered by hand, device worked first try
<q3k>
(he has, on the siglent scopes we're messing around with)
genii has joined ##openfpga
<G33KatWork>
twice
<G33KatWork>
first time it was only one chip, second time it was two
<whitequark>
mad skills
<q3k>
but then he was impressed with my magnet-wire-to-qfn hacks
<q3k>
which is something that just does not compute
<G33KatWork>
eh
<G33KatWork>
maybe I just wanted you to feel good? :P
<whitequark>
it's very irritating, but not complex
<G33KatWork>
I'm joking, man
<whitequark>
hand tremors are the worst
<G33KatWork>
I should get a microscope for stuff like that
<whitequark>
while i was on clomipramine recently i had hand tremors so bad i couldn't solder two wires together in ~30 minutes. nearly broke down crying
<whitequark>
that drug isn't bad but *fuck* hand tremors
<q3k>
G33KatWork: the one I have is decent, have I made you use it when you were over?
<G33KatWork>
nope
<q3k>
G33KatWork: still not a proper x/y stage, but Cheap Enough
<q3k>
G33KatWork: wait a few months and I can sell it to you, as I'm thinking of upgrading :P
<G33KatWork>
lol
<G33KatWork>
Because it's totally my thing to buy cheap gear, eh?
<G33KatWork>
hint: it's not
<G33KatWork>
well, okay. the hot air station is china cheapo stuff
<G33KatWork>
didn't feel like spending 2K on a weller or jbc hotair
<q3k>
and I thought I was hardcore for doing SMT with a gas iron
<gruetzkopf>
he's seen the result of blowtorch + unqualified operator vs pcb
<gruetzkopf>
the smell of burning fr4 *shudder*
<whitequark>
ugh
<q3k>
still better than phenolic paper laminate smell when you so much as lightly heat it with an iron
<whitequark>
i opened up my old magstirrer
<gruetzkopf>
ugh, yes
<whitequark>
not only it had an FR-2 PCB, but it also looked like they broke it up by manually bending until it cracks
<whitequark>
well it was surely not cut by a router
<gruetzkopf>
guess who improvised a backplane on a 19" by 3U piece of FR2 perfboard last week
<qu1j0t3>
YOU!
<whitequark>
wtf
<whitequark>
why
<gruetzkopf>
because it needed to be done the day before i even got there..
<whitequark>
"FR-2 can be machined by drilling, sawing, milling and hot punching. Cold punching and shearing are not recommended, as they leave a ragged edge and tend to cause cracking."
<whitequark>
oh
<whitequark>
shearing
<whitequark>
that's what they did
<q3k>
still better than getting silicosis from cutting/grinding fr4
<q3k>
(and ruining your tools on it)
<whitequark>
the dangers of fr4 are overrated
<qu1j0t3>
overstated? :)
<whitequark>
overstated
<gruetzkopf>
shipping on 130mm * 480mm boards is annoyingly expensive
<q3k>
order a flex so they can roll it up
<gruetzkopf>
> backplane > flex > cheap
<q3k>
well, you wanted cheap shipping, not cheap manufacture :P
<gruetzkopf>
i mainly want cheap result ;)
<G33KatWork>
second chip done
<G33KatWork>
I'm getting faster
<G33KatWork>
this thing will never work again
<G33KatWork>
there is no chance that I solder 8 bga chips flawlessly by hand
<G33KatWork>
maybe I can play around with coreboot and solder just a few chips first and check out if they work with less capacity and bandwidth
<G33KatWork>
but I don't have a board schematic, so I don't know which DQ lines from the SoC are connected to which chip :/
<G33KatWork>
and I don't know what configs that chip supports at all
<whitequark>
boundaryscan?
<G33KatWork>
dunno. Never used JTAG on intel chips
<G33KatWork>
JTAG on intel chips always feels like undocumented NDA secret sauce magic
<gruetzkopf>
every time i look at board prices they seem to be lower
<whitequark>
intel publishes a lot of bsdl files
<whitequark>
even for their server chipsets
<whitequark>
-- Version : Release 0.9 (Have not validated in internal platform, Not for customer release)
<whitequark>
lol
<gruetzkopf>
:D
<gruetzkopf>
10/10 would trust for board test
<whitequark>
which soc?
<G33KatWork>
Intel Pentium N3710
<whitequark>
what the fuck
<whitequark>
BSDL files are ADA CODE?!
<G33KatWork>
kind of
<q3k>
oh yes they are
<G33KatWork>
derived from ADA and VHDL afaik
<q3k>
yep
<whitequark>
what sick fuck came up with that?
<G33KatWork>
all the same language family
<q3k>
always looked like vhdl to me
<q3k>
whitequark: the same sick fucks who came up with vhdl
<whitequark>
and why does it embed massive tables as strings?
<q3k>
whitequark: if you have a flat structure like that with a super simple schema just use a tab-separated text file
<q3k>
still better than json
<q3k>
at least you won't be pretending it's a standard
<whitequark>
then you have to invent a whole new format if it becomes a little bit more complex
<q3k>
json doesn't help you here, you'd have to start defining schema and versioning sooner or later
<q3k>
none of which json helps with
<q3k>
just use protobufs
<whitequark>
flatbuffers
<q3k>
well-defined wire format, designed for making backward-and-forward compatible schemas, parsers/emitters for nearly any language you want, built in textual representation for human oogling
<whitequark>
which can serialize to json :P
<whitequark>
but yes, you have a point on the schema
<q3k>
schemaless interchange formats with no unicode support make me cry
<q3k>
and yeah, without an actual respected spec
<q3k>
because the creatow wanted to have a meme on his business card
<q3k>
*creator
<q3k>
if you love curly braces and lack of schemas at least use http://jsonnet.org/
<q3k>
bonus: it's turing complete and horrifying
<q3k>
extra bonus: show this to a googler and see them get flashbacks from bcl/gcl
<G33KatWork>
crashes if using more memory than n megabytes
<G33KatWork>
don't know the exact value for n
<G33KatWork>
looks like an adressing isue
<G33KatWork>
also it turns off, then on again after a while. it's not only a crash. so something in that soc is panicing. most likely the management engine which in this soc is called TXE
<balrog>
and you know it's not bad RAM?
<balrog>
or bad / iffy firmware
<G33KatWork>
reflashed the firmware already
<G33KatWork>
could be a broken chip
<G33KatWork>
it's definitely not the solder joints on the chips though :D
<G33KatWork>
but it smells like one of the higher address bits is stuck, not connected, whatever
<G33KatWork>
I don't know exactly how this soc does the ddr3 training and what lines need to be okay for it to pass, because that seems to work
<G33KatWork>
it tries to boot windows, then crashes
<G33KatWork>
linux boots as well but it shows the same symptoms when using a bit more memory
<lain>
interesting
<balrog>
boot memtest?
<G33KatWork>
crashes
<G33KatWork>
my theory is that something overwrites memory for the TXE, the TXE detects this or crashes and turns off the chip to prevent itself from being screwed around with
<lain>
TXE is rude
<lain>
but also kinda necessary for those SoCs to boot
<lain>
they did some neat stuff with it in those
Bike has quit [Ping timeout: 260 seconds]
<G33KatWork>
problem is, it's only a theory. I could be completely wrong