11:03 <_florent_> kbeckmann: your ideas are interesting could be nice contributions! The idea with the bios is to keep it simple and flexible, some of the improvements ideas: add sd card boot support, improve oses booting (Linux, Zephyr, micropython, etc...), have the same features for all the suppported CPU, etc...

11:07 <_florent_> kbeckmann: so being able to re-program the flash directly from the bios would definitely be useful for various use cases (being able to reflash software or the bistream with it without using jtag cable), and should not add too much complexity since we already have the flash support

11:46 <kbeckmann> _florent_: cool then I'll keep that in mind and clean up my patches and submit a few PRs in the coming weeks or so.

20:21 <somlo> _florent_: I'm wondering what the difference is between LiteDRAMWishbone2AXI (https://github.com/enjoy-digital/litedram/blob/master/litedram/frontend/wishbone.py#L55 introduced in litedram commit ca82ac18) on one hand, and the AXI2Wishbone converter in LiteX proper (https://github.com/enjoy-digital/litex/blob/master/litex/soc/interconnect/axi.py#L333)

20:21 <tpb> Title: litedram/wishbone.py at master · enjoy-digital/litedram · GitHub (at github.com)

20:22 <somlo> are they doing the same general type of thing? The former is not in use anywhere right now that I can find, is it dead code, or were you planning on using it for something specific at some point in the future?

20:26 <_florent_> somlo: the direction are different, one is Wishbone --> AXI, the other AXI --> Wishbone, i'm using Wishbone2AXI on another project, but this should probably be integrated in LiteX directly

20:29 <somlo> oh, so the one in LiteDRAM is for when wishbone is the master port, and axi the slave

20:30 <somlo> or no, wait, that's *my* scenario, I have axi master -> wishbone master, and litedram has the slave port :)

20:33 <somlo> so I think what I *really* need is a native AXI data_width converter, same as what wishbone.Converter() does, except natively for AXI

21:43 <scanakci> somlo: I have a question. https://pastebin.com/8bWCnWR5. Here, have CSRs(including DRAM_init), bootrom as wb slaves. In core.py, there are "rom" : 0x10000000, "sram" : 0x11000000, "csr" : 0x12000000,"ethmac" : 0x30000000

21:44 <scanakci> I guess bootrom resides at "rom" address, and the first code that cpu executes. Next, bios is executed, which resides in sram. Is this correct? Also, what does DRAM_init refer to in the figure?

21:58 <somlo> IIRC, the bios is in bootrom, located at the "rom" address. It's treated as "read-only", which is why the stack is set to the read/write-able sram

21:59 <somlo> dram init is the MMIO register (CSR in the LiteX vernacular) used by the bios to initialize the LiteDRAM controller, before its axi or wishbone datapath can be used to send/receive data from the actual RAM

22:00 <somlo> *registerS (plural, there are probably several of them)

22:21 <scanakci> I see. Thanks, this clears my confusion. I was a bit confused since you mentioned that bios is in SRAM. "somlo: I think the bios is always in SRAM, whether simulated or part of an fpga bitstream image"

23:42 <somlo> well, in that context I *meant* RAM that's on the FPGA (as opposed to DRAM via liteDRAM, or some other off-chip memory) :)

23:43 <somlo> Litex uses on-FPGA memory for the "rom" which it *could* write over, but chooses not to, and the "sram" which is the same kind of memory, but designed to be writeable as well

23:43 <somlo> scanakci: ^^

23:48 <scanakci> somlo: thanks, it is more clear now :)