17:08 <sajattack[m]> am I the only one getting a kernel panic running spisdcardboot?

17:19 <somlo> works great for me booting (bbl(linux-riscv64(busybox))) on litex+rocket

17:19 <sajattack[m]> post #435 and #436?

17:20 <somlo> at litex commit c547b2cc (as of a few hours ago

17:21 <sajattack[m]> hrm

17:21 <sajattack[m]> maybe my buildroot got messed

17:22 <somlo> actually, much faster than before (with the reclocking thing)

17:22 <sajattack[m]> let me try the official images

17:22 <somlo> not sure about buildroot -- I have busybox built into the kernel, wrapped inside BBL, as a single boot.bin file

17:25 <somlo> now I need to figure out how to make the SPI-mode SDCard visible to the Linux kernel, so I can mount it once I'm done booting

17:26 <somlo> I know there's "mmc_spi" to start, but no idea if it'll work out of the box or if it might need a bit of "surgery" first :)

17:33 <sajattack[m]> I keep getting this https://ghostbin.co/paste/rp7p4

17:34 <tpb> Title: rp7p4 - Ghostbin (at ghostbin.co)

17:34 <sajattack[m]> or some variation thereof

17:34 <sajattack[m]> sometimes it says the initramfs contains junk or something

17:34 <sajattack[m]> other times it kernel panics even earlier

17:35 <somlo> sajattack[m]: fwiw, we're exercising different #ifdef branches of spisdcardboot(), but we both have at least one spi_sdcard_readFile() and one boot() call in there

17:36 <sajattack[m]> ok

17:36 <somlo> so I think those work fine for both of us. It's what happens once you jump to the data you transferred over into memory that things go south for you

17:36 <sajattack[m]> yeah

17:36 <sajattack[m]> memtest is ok

17:37 <sajattack[m]> but maybe the sdcard is dirty somehow

17:37 <somlo> could be the stuff you transfer over is already corrupted somehow, or maybe some overrun of some kind ?

17:38 <somlo> I haven't played with vexriscv linux, so I don't know much about all the ways it can go wrong

17:39 <sajattack[m]> it worked before reclocking

17:39 <somlo> easy (if maybe a bit time consuming) would be to check out a pre-reclocking commit and build that, see if reclocking consistently breaks it for you

17:39 <sajattack[m]> yeah

17:39 <somlo> i.e, "git bisect" :)

17:40 <somlo> then you'd have a specific commit to blame for your troubles, and a slightly smaller problem space to deal with

17:42 <sajattack[m]> idk git bisect but I can git log and git checkout

17:43 <somlo> sajatacc[m]: web‪chick.net/node/99 (there's many more guides if you google)

17:43 <somlo> you'll love it :)

17:44 <somlo> pick a commit that works, pick one that breaks, let git tell you which ones to try until you find the one that broke your stuff

17:44 <sajattack[m]> cool

18:10 <sajattack[m]> `2bf31a31da336b628825aced248396b8ba3e3105 is the first bad commit`

18:10 <sajattack[m]> as I suspected