<Melkhior>
@somlo : for the micro-sd card, weirdly enough:
<Melkhior>
[dolbeau2@localhost litesdcard]$ git bisect bad
<Melkhior>
0754ce82530d62e89871d0c3be41c0082560aeef is the first bad commit
<Melkhior>
also if I update to litesdcard master (17f6216caa1dc156546ebd4208082aca35b16221 ATM) and reverse that one commit (that one line!), then it works-for-me in LoLV's BIOS ....
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<Melkhior>
@somlo please remember this could be borderline hardware, even though the behavior is fairly consistent
<somlo>
given that it only worked for you under a very narrow set of conditions anyway, I wonder if we're tickling some other bug...
<Melkhior>
also while I don't know what happens under LInux with that one extra line (as it won't load at all), without it reading is fine in SMP mode and returns randomly corrupted data in UP mode (with no indication in dmesg that anything is wrong with the sdcard, not timeouts, no nothing)
<Melkhior>
also: I just tried to _write_ to the sdcard (which has so far never worked), and the console just hanged
<Melkhior>
after rebooting, no trace of the file - which is consistent with what I've seen before: hangs or no hangs, the filesystem seems unchanged by attempted write (not even an empty file indicating an update of metadata)
<Melkhior>
(still running geertu's v5.11 kernel built by buidroot ATM, so I may not have the latest sdcard driver in linux ... but that doesn't matter at all for BIOS)
<somlo>
yeah, no, the bios has nothing to do with the linux driver...
<somlo>
remind me, is this with one of the existing boards in litex-boards, or some new model you're trying to add support for?
<somlo>
in the first case, I think we should revert 0754ce8 and ask questions later
<somlo>
in the second case, is this happening for multiple exemplars of the same board, or are we just dealing with "marginal" hardware perhaps?
<somlo>
_florent_: ^^^
<somlo>
"this should not make a difference" (but then, neither should smp-vs-single-core :) )
<Melkhior>
it's my 'new' hardware (which is a perfectly fine commercial board plugged into an adapter board, the adapter only has the LEDs, serial port, untested JTAG and the micro-sd card slot in question ; there's also a SBus connector but I don't use that for LiteX:-) )
<Melkhior>
... and there's just one working with a micro-sd card slot (the 2nd board in existence works fine as well for everything else, but I somehow managed to have a broken micro-sd card lid on it...)
<Melkhior>
so I wouldn't reverse it just for me
<Melkhior>
running a single-core 45.8 MiB stream benchmark ATM as i've never really stressed the memory before
<Melkhior>
(crypto is very much *not* bandwidth-bound)
<Melkhior>
well, 22.9 MiB once I've moved from 'double' to 'int', as I don't have a FPU (yet, from the look of dolu's fpu branch) 'double' is quite slow :-)
<somlo>
Melkhior: getting into pcb design is still a "todo" item on my bucket list... :) Along with taping out actual silicon (I was going to sign up for the relevant ECE course sequence here at my uni, but then covid came along and taking classes got weird...)
<Melkhior>
it's a very simple pcb - it just route signals between the SBus connector and the pin headers to the ZTex board, plus the serial/jtab/leds/sd-card signals, all of them simple (and I may have botched the sd-card!)
<Melkhior>
no-one has made a SBus board for 20+ years so I had to roll out my own :-)
kgugala has joined #litex
<Melkhior>
the miracle is that there was still some connectors in stock @ mouser, they are EOL now...
<Melkhior>
interestingly, running a couple of copies of stream at once neither takes much of a it (dual-core); running 4 half the banwidth, but that's probably just the sharing of one core for two copies
<Melkhior>
seems the memory subsystem is not a bottleneck for the dual 80 MHz VexRiscv
<Melkhior>
wish I had a bigger FPGA for more cores :-)
kgugala_ has quit [Ping timeout: 272 seconds]
<Melkhior>
@somlo as for taping out silicon ... i'll let my hardware colleague handle that :-)
<somlo>
@Melkhior: it's not like anyone's getting anywhere near a foundry, but students get to use all the design tools to generate the masks, that then get sent off for fabrication. Next semester you get to deal with whatever they send you back for a final grade :)
<Melkhior>
wish I could have done that at uni :-)
<Melkhior>
never got anywhere near hardware design, architecture was the closest we got
<Melkhior>
idly wondering if I could get a SBus device in the Skywater 130nm process now that the PDK is accessible :-)
<Melkhior>
but by the time I've had time to understand all of it, I won't be able to get connectors anyway...
Bertl_oO is now known as Bertl
<somlo>
yeah, Skywater is for "self-starters". I need the threat of getting a "bad grade" to trick myself into sticking with learning something new long enough to... well, *learn* something :)
<Melkhior>
:-)
<somlo>
or at least someone I believe knows something teaching me, as opposed to me flailing around on my own :)
<Melkhior>
or needing the skill for a project you really want to do - at least that works for me:-) that SBus/FPGA thing had been in my head too long, when I joined a HW company I figured it would help me learn the vocabulary of the HW people; it worked... now I know what 'WNS' mean and why it's bad :-)
<cr1901_modern>
_florent_: I'm not sure the best way to handle this, but as a heads-up... binutils 2.35/6 has gotten stricter about invalid linker options. It appears that -nodefaultlibs is not a valid option, and causes building the BIOS to error
<cr1901_modern>
-nostdlib is, incidentally, still accepted
scanakci has joined #litex
feldim2425 has quit [Quit: ZNC 1.8.x-git-91-b00cc309 - https://znc.in]