cr1901_modern1 has quit [Read error: Connection reset by peer]
kgugala has joined #litex
kgugala__ has quit [Ping timeout: 268 seconds]
peeps[zen] is now known as peepsalot
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 240 seconds]
Melkhior has joined #litex
cr1901_modern has joined #litex
peepsalot has quit [Ping timeout: 246 seconds]
Billy_ has joined #litex
Billy_ is now known as fly
peepsalot has joined #litex
<Melkhior>
@somlo About the micro-sd card; I have a new board for LiteX where the sd-card works better than on my custom carrier (that I used previously for LIteX); which kernel (git/branch/commit/...) would you recomment at this time? I can boot Yocto from a sd-card root, but I have random issues that seem related to sd-card access (buildroot works
<Melkhior>
apparently fine, but is much lighter on storage I/O...) Currently booting the commit pointed to by linux-on-litex-vexriscv.
<Melkhior>
TIA
Bertl_oO is now known as Bertl_zZ
hansfbaier has joined #litex
hansfbaier has quit [Quit: WeeChat 2.8]
<Melkhior>
@somlo tried branch litex-rebase, but it dies during boot after timed-uot CMD18: https://pastebin.com/ScJ7WX93
<tpb>
Title: [ 1.291426] mmc0: new SDHC card at address 0001[ 1.299177] mmcblk0: mmc0 - Pastebin.com (at pastebin.com)
<somlo>
@Melkhior: I just rebased litex-rebase again, and put back the restriction to single-block transfers
<Melkhior>
I'm trying on the previous commit, I got to the login prompt
<somlo>
with multi-block, reads are about twice as fast as before, but (large) writes will cause a hard lock-up of kernel and/or gateware, whereas large single-block writes might fail silently but leave the system still operational otherwise
<Melkhior>
it's trying to log me in but that was very slow on the regular kernel as well
<somlo>
_florent_ is looking at the gateware, I've been pretty busy over the last week, didn't have a chance to do anything on my end
<Melkhior>
no problem, just wanted to know what I needed to test with VexRiscv
<Melkhior>
as you're working with Rocket
<somlo>
right, thanks!
<Melkhior>
I'm on the sdcard because I couldn't get the Ethernt to work in Linux :-)
<somlo>
my test is: `mount /dev/mmcblk0p1 /mnt; cp /mnt/boot.bin /root/foo; cp /root/foo/mnt/; umount /mnt; mount /dev/mmcblk0p1 /mnt; md5sum /mnt/*`
<Melkhior>
otherwise NFS would be easier to have a large FS accessible
<somlo>
the idea is after mounting the second time, /mnt/boot.bin and /mnt/foo should have the same md5sum
<Melkhior>
yes they definitively should...
<Melkhior>
I've gone one further:
<Melkhior>
root@litex-riscv32:/root# mount | grep mmc
<somlo>
which only happens for me with single-block, *and* if I further slow down the sdclock to max out at 12.5MHz :)
<Melkhior>
dev/mmcblk0p2 on / type ext4 (rw,relatime)
<somlo>
otherwise (full 25MHz sdclock) the write fails silently in single-block mode; in multi-block mode, the write locks up the system at any sdclock (limited or not)
<somlo>
Melkhior: yeah, any *fancy* filesystem (i.e., fancier than fat16 :) ) will involve lots of housekeeping writes (unless you mount r/o)
<Melkhior>
mmm, I'm 4 cores @ 85 MHz so:
<Melkhior>
[ 1.788867] litex-mmc f0006000.mmc: Requested clk_freq=0: set to 332031 via div=256
<Melkhior>
[ 1.808410] litex-mmc f0006000.mmc: Requested clk_freq=12500000: set to 10625000 via di
<Melkhior>
v=8
<Melkhior>
[ 1.845192] litex-mmc f0006000.mmc: Requested clk_freq=25000000: set to 21250000 via di
<Melkhior>
v=4
<somlo>
and those writes will sometimes fail, because the (gateware x linux_driver) combo is still having some issues...
<Melkhior>
slower than 25 MHz but faster than 12.5
<Melkhior>
have you tried intermediate speed or just an increased divisor going straight from 25 to 12.5 ?
<Melkhior>
despite that, copying a 12 MiB file seemed to work... same md5sum after reboot
<somlo>
Melkhior: although the output you pasted seems somewhat orthogonal to any sdcard issues, not sure I see a strong link there
<Melkhior>
me neither, but more often that not it's rdisc
<Melkhior>
maybe some I/O issue causing weird behavior to random programs ?
<Melkhior>
I'll have to re-test a buildroot root as well
<Melkhior>
compilation issue would be deterministic accross reboot
<Melkhior>
core issue would probably also affect buidlroot
<Melkhior>
so I'm guessing I/O to the root FS as yocto is more intensive
<Melkhior>
but I agree it's just a guess and not substantiated by the output in dmesg :-(
<Melkhior>
Buildroot has no apparent issue; of course it starts a lot fewer processes during boot as well...
<Melkhior>
No idea how to figure out what is causing those semi-random failures in Yocto... any suggestions welcome!
<Melkhior>
The only thing that points to the sd-card subsystem is that when there's no 'living dead' process (100% cpu, unkillabe, flagged aby rcu_sched), then auto-comlpetion is decently fast... not particularily conclusive :-(
<Melkhior>
anyway, will try to figure out the yocto issue as time permits