00:40 <sajattack[m]> it built an x64 gdb targeting riscv >:(

00:42 <sajattack[m]> when it was set to cross it did, when I set it to native or cross-native it just nopes out

00:46 <sajattack[m]> [ERROR] No code for 'native' toolchain type!

05:48 <sajattack[m]> I built gdb by hand and now my kernel keeps panicking

05:48 <sorear> that seems bad

05:49 <sajattack[m]> well the rootfs did grow to 18MB

05:49 <sajattack[m]> I'm guessing the dodgy uart is corrupting a certain percentage of the bits

05:50 <sorear> you might also try getting a core dump off the system and then transfering it somewhere else with a gdb

05:50 <sajattack[m]> on 2nd thought, maybe I should do a clean buildroot instead of just trying the same one over and over and expecting a different resutl

07:32 <sajattack[m]> still kernel panicking

07:32 <sajattack[m]> says /sbin/init does not exist

07:32 <sajattack[m]> https://hastebin.com/ronelewete.yaml

07:32 <tpb> Title: hastebin (at hastebin.com)

07:54 <sajattack[m]> <sorear> "you might also try getting a..." <- I would think it's easier to get gdb into the ramfs via buildroot than try to extract a coredump but I could be wrong

11:51 <acathla> I'm a little lost between add_spi_flash (which uses litespi), SpiFlash (which doesn't seems to use SPIMaster) and what does a timeline do? It's not even in the migen documentation and there are almost no comment.

11:51 <acathla> What's the recommended way to add a SPI flash to a SoC now?

11:55 <_florent_> acathla: We are progressily switching the different boards in LiteX-Boards to LiteSPI

11:55 <_florent_> SpiFlash is still present in the integration for retro-compatibility

11:59 <_florent_> but the choice can vary, it depends on your needs: If you need fast MMAP: use LiteSPI, if you want a simple SPI Flash support for just a few writes/reads: use the SPIFlash core, if you need something very minimal use SPI bitbanging.

11:59 <acathla> ICESTORM_LC: 5515 with the add_spi_flash versus 5211 with old SPIFlash

12:00 <acathla> I need MMAP and SPI to read other SPI chips. That's going to be complicated...

12:01 <acathla> Ok I'll try bitbang for the other chips and keep SPIFlash for now.

12:21 <tnt> 5211 ... out of 5280 ? cutting it close :)

12:22 <_florent_> acathla: LiteSPI is indeed not resource efficient for now: https://github.com/litex-hub/litespi/issues/54

12:22 <_florent_> you can probably stay with the old SPI Flash core for now

12:23 <leons> so it's ... HeavySPI? :D

12:24 <leons> I'm not even gonna try making any more jokes today, I'm sorry :)

12:25 <acathla> tnt, it builds! :)

12:25 <_florent_> leons: hehe don't worry I also had it in mind just before you wrote it :)

12:27 <acathla> There was a discussion somehere about the hardware SPI in iCE40 but I forgot the conclusion...

12:30 <tnt> (1) it's not memory mapped, you can't XIP from it

12:31 <tnt> (2) I mean, if you're short on LCs, it works but it's not exactly the speediest option.

21:52 <tcal> I also noticed with the recent liteSPI changes, on Fomu, my intern's design that used to be at 5234/5280 :) is now over by a couple of hundred LCs.

22:00 <tcal> It was already using liteSPI , I pulled in changes from 3f6b32b0 (about a month and a half ago) to current.