Xark has quit [Ping timeout: 268 seconds]
Xark has joined #litex
_whitelogger has joined #litex
<_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
keesj has quit [Ping timeout: 240 seconds]
rohitksingh has joined #litex
rohitksingh has quit [Ping timeout: 260 seconds]
<tpb> Title: [Diff] diff --git a/litesdcard/firmware/sdcard.c b/litesdcard/firmware/sdcard.c index - Pastebin.com (at pastebin.com)
<somlo> not sure it's worth sending a PR over it, but I can if you want me to :)
<somlo> but we shouldn't have global variables declared in a .h :)
<somlo> s/declared/defined/
<_florent_> somlo: thanks, i can apply that. firmware.c can indeed probably be improved.
<somlo> besides, it doesn't *need* to be global, as only sdcard_init actually uses it
<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
<somlo> and I noticed this while working on wrapping #ifdef CSR_SDCLK_BASE ... #endif around everything :)
<_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)
<somlo> then get a Linux driver for it, and boot from a pre-populated rv64gc distro image :)
<somlo> _florent_: are sdinit/sdtest likely to destroy the data I have on the sdcard? :)
<_florent_> somlo: sdinit no, but sdtest will write some blocks yes...
<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
<kbeckmann> verify the migration.
<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
<tpb> Title: __ _ __ _ __ / / (_) /____ | |/_/ / /__/ / __/ - - Pastebin.com (at pastebin.com)
<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
<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 :)
<_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
<tpb> Title: litex/core.py at master · enjoy-digital/litex · GitHub (at github.com)
<_florent_> kbeckmann: then yes i want to continue adding unit tests and do more test with the nmigen compat mode
<kbeckmann> oh, that's interesting. thanks for the link.
<somlo> _florent_: interesting, now my sdcard is completely broken, getting buffer i/o errors when trying to open it on Linux :)
<somlo> not entirely sure if it was sdtest or maybe it just died of old age and abuse, in a weird coincidence :)
vup2 has quit [Quit: No Ping reply in 180 seconds.]
<_florent_> somlo: formating SDCards with the core can also be a use-case :)
gruetzkopf has quit [Remote host closed the connection]
vup has joined #litex
gruetzkopf has joined #litex
<somlo> _florent_: after several tries I managed to re-format it and use it again
<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
<somlo> then create a partition to overlap with that in a way that protects my other data
<somlo> then retry, then we'll see what's going on
<somlo> also, I think CSR_SDCORE_RESPONSE_* is a good candidate for a unified >64bit CSR read function...
tpb has quit [Remote host closed the connection]
tpb has joined #litex