10:06 <futarisIRCcloud> https://twitter.com/tpetazzoni/status/1211217995294498818?s=19

12:11 <_florent_> futarisIRCcloud: nice, now the next step would be to boot the kernel from the SD-Card with LiteX's bios (i'll try to prototype it)

13:09 <mithro> _florent_: Any idea what is up with needing the sram at address 0 on the ice40?

13:29 <_florent_> mithro: is it that sram needs to be at address 0 or that something (even if not used) needs to be mapped at 0?

13:30 <mithro> _florent_: It seems to be something like that

13:30 <mithro> _florent_: Still working to debug a bit

13:31 <mithro> _florent_: We definitely have a non-zero cpu reset address

13:33 <_florent_> mithro: is it really related to ice40? or is it also happening on others devices that have the BIOS in SPI flash?

13:47 <rvense> _florent_: don't think we know, it came up when i tried to get the hx8k evb board going

13:51 <_florent_> mithro, rvense: i just tried to reproduce the issue with lxsim, mapping the rom to 0x2000000 instead of 0x00000000, but it's working fine (so with nothing mapped to 0x00000000)

14:35 <mithro> _florent_: Will try and a more reproducible result

15:31 <xobs> mithro: the UARTStub is just a bunch of CSRs that don't actually do anything: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/uart.py#L226-L243

15:31 <tpb> Title: litex/uart.py at master · enjoy-digital/litex · GitHub (at github.com)

15:32 <xobs> I suppose you could wrap it in a UARTMutliplexer, but your idea is kind of my idea behind the Messible https://github.com/betrusted-io/betrusted-soc/blob/master/gateware/messible.py

15:32 <tpb> Title: betrusted-soc/messible.py at master · betrusted-io/betrusted-soc · GitHub (at github.com)

15:40 <mithro> xobs: I was sure there was a version of the UART which was just two FIFOs for buffering -- _florent_ am I imagining things?

16:06 <rvense> um, so right now it looks like vexriscv is just ignoring jump instructions

16:07 <rvense> i'm guessing there's something we're overlooking..

16:14 <xobs> rvense: Is it executing from SPI?

16:14 <rvense> yeah

16:14 <rvense> https://rven.se/pile/gdb1.txt

16:15 <xobs> rvense: Do you have the base.py available anywhere?

16:17 <rvense> https://rven.se/pile/base.py

16:18 <xobs> Maybe your SPI Flash isn't the correct endianness?

16:18 <xobs> https://github.com/im-tomu/foboot/blob/master/hw/foboot-bitstream.py#L212

16:18 <tpb> Title: foboot/foboot-bitstream.py at master · im-tomu/foboot · GitHub (at github.com)

16:19 <rvense> i don't know that, no

16:19 <xobs> Add `endianness="little"` to it, if you're using aVex

16:26 <rvense> facedesk

16:32 <xobs> That one took me a while to figure out, too.

16:35 <rvense> it's still not working right though

16:44 <xobs> What's your spiflash_read_dummy_bits set to? Try `6` or `4`.

16:54 <rvense> it's set to 8

17:01 <rvense> changing it seems to break things even more

18:28 <xobs> rvense: I added some example of how to use the wishbone bridge to debug at https://github.com/xobs/wishbone-utils/#debugging-using-the-bridge

18:28 <tpb> Title: GitHub - xobs/wishbone-utils: Utilities for working with a Wishbone bridge (at github.com)

20:28 <_florent_> mithro, xobs: the default UART is composed of: CSRs + Tx/Rx FIFO + Tx/Rx RS232 PHY, but the PHY can be replaced by something else or just removed).

23:42 <futarisIRCcloud> https://github.com/pdp7/talks/blob/master/oshw-linux-36c3.pdf / http://streaming.media.ccc.de/36c3/relive/10549

23:42 <tpb> Title: talks/oshw-linux-36c3.pdf at master · pdp7/talks · GitHub (at github.com)