09:54 <_florent_> somlo: for the card_detect, IIRC we were not using it or managing it externally, but this could be useful to let LiteSDCard manage it

16:34 <somlo> _florent_: https://pastebin.com/chupVmd3

16:34 <tpb> Title: [Diff] diff --git a/litesdcard/firmware/sdcard.c b/litesdcard/firmware/sdcard.c index - Pastebin.com (at pastebin.com)

16:34 <somlo> not sure it's worth sending a PR over it, but I can if you want me to :)

16:35 <somlo> but we shouldn't have global variables declared in a .h :)

16:35 <somlo> s/declared/defined/

16:37 <_florent_> somlo: thanks, i can apply that. firmware.c can indeed probably be improved.

16:37 <somlo> besides, it doesn't *need* to be global, as only sdcard_init actually uses it

16:38 <somlo> I'm trying to import the sdcard.c code into the litex bios binary, as opposed to just running the firmware tester as part of litesdcard

16:39 <somlo> and I noticed this while working on wrapping #ifdef CSR_SDCLK_BASE ... #endif around everything :)

16:42 <_florent_> ah interesting, that would be great to have a sdcardboot capability :) (just copy raw data from the SDCard to SDRAM and boot to it)

16:44 <somlo> then get a Linux driver for it, and boot from a pre-populated rv64gc distro image :)

17:12 <somlo> _florent_: are sdinit/sdtest likely to destroy the data I have on the sdcard? :)

20:21 <_florent_> somlo: sdinit no, but sdtest will write some blocks yes...

20:29 <kbeckmann> _florent_: the question about litex + nmigen came up again in another discussion forum. did you have some ideas about how to approach this already? was the idea to allow instantiation of nmigen modules in a litex project? another obviously riskier option would be to migrate the codebase to the migen compatibility mode in nmigen, and i remember you mentioning lack of unit tests being a problem here in order to

20:29 <kbeckmann> verify the migration.

20:30 <somlo> _florent_: figured it out meanwhile... "luckily" for my sdcard (not that I have anything irreplaceable on it) the write test failed (initialization succeeded, though): https://pastebin.com/7qH1CCEx

20:30 <tpb> Title: __ _ __ _ __ / / (_) /____ | |/_/ / /__/ / __/ - - Pastebin.com (at pastebin.com)

20:31 <somlo> I think it fails setting the block count, then blindly tries writing a block and I think I get a hardware lockup, since it stops outputting anything

20:34 <somlo> that's with 32-bit csr data width, now trying again with 8. Used mor1kx since I already have a toolchain for it, and the default litesdcard firmware was also targetting a big-endian cpu. I'm getting the same on vexriscv, btw. didn't even try rocket, not yet having had a chance to sanitize the code for 64bit :)

20:40 <_florent_> kbeckmann: i did a first test with Minerva that is elaborated directly with nMigen during the build: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/cpu/minerva/core.py#L89-L102

20:40 <tpb> Title: litex/core.py at master · enjoy-digital/litex · GitHub (at github.com)

20:40 <_florent_> kbeckmann: then yes i want to continue adding unit tests and do more test with the nmigen compat mode

20:48 <kbeckmann> oh, that's interesting. thanks for the link.

21:06 <somlo> _florent_: interesting, now my sdcard is completely broken, getting buffer i/o errors when trying to open it on Linux :)

21:07 <somlo> not entirely sure if it was sdtest or maybe it just died of old age and abuse, in a weird coincidence :)

21:48 <_florent_> somlo: formating SDCards with the core can also be a use-case :)

22:19 <somlo> _florent_: after several tries I managed to re-format it and use it again

22:20 <somlo> so maybe overwriting block 0 really annoys the sdcard hardware -- I'll try to rewrite the test to use blocks from the *end* (as opposed to the beginning) of the device

22:20 <somlo> then create a partition to overlap with that in a way that protects my other data

22:20 <somlo> then retry, then we'll see what's going on

22:32 <somlo> also, I think CSR_SDCORE_RESPONSE_* is a good candidate for a unified >64bit CSR read function...