05:17 <joshua_> Hi! I am back, some time later. I'm trying to figure out a reasonable flow to build software as part of my LiteX build. Basically, I want to have my firmware compiled into the bitstream, with a single large SRAM (i.e., no ROM-to-SRAM copy). I think I want a flow that is similar to the BIOS build flow, but instead of the BIOS, I want to build, say, the LiteX bare metal demo.

05:57 <ysionneau> joshua_: I can see in soc_core.py you can easily add ram/rom to the SoC but you need to pass directly the binary file to init the ramblock, you can't just pass a path that will get built

05:57 <ysionneau> so I don't think litex supports for now adding other build than the bios, but I might be wrong :o

05:59 <ysionneau> I also looked at builder.py which contains the logic to build the bios but it seems it only builds bios and basic libraries

06:00 <ysionneau> but maybe logic can be extended/generalized in builder.py ?

06:02 <ysionneau> maybe the add_ram() / add_rom() from the SoC class can be extended to be called with a path/build type info (makefile/meson/cmake etc) to tell how to build the content of those rams

06:03 <ysionneau> then builder.py can "finalyze" everything and build those, like it's done for the bios

06:11 <joshua_> I think I am making some progress by doing a `builder.add_software_package`

06:11 <joshua_> and indeed I am doing s `self.init_rom('main_ram', get_mem_data('demo.bin', endianness = 'little', data_width = 32))

06:11 <joshua_> `

06:12 <joshua_> but I am sort of lost in how I would specify the correct path to `demo.bin` from __init__ in a SoCCore, before the builder has even done its work yet

06:13 <ysionneau> ah yes you're right, _generate_rom_software() seems to build everything it finds in self.software_packages

06:13 <ysionneau> so maybe it's ok like this

06:15 <joshua_> maybe I can override `build` in my SoC object

06:25 <joshua_> I think I have achieved this

06:25 <joshua_> if this actually runs correctly on my board I will pastebin it

06:36 <joshua_> https://gist.github.com/jwise/827ee5e26e1cdea7aa636542bf772547 this is how I achieved this

06:42 <ysionneau> seems like a bit of a "hack" but I guess it's a good start until someone adds proper support

06:43 <joshua_> yes, the situation is not great

07:04 <zyp> joshua_, beware that if you don't split .data into a RW area and a RO area of initial values, you can't reset the CPU without reloading the whole FPGA

07:04 <joshua_> that explains why I could not reset the CPU

07:14 <joshua_> is it still the case that 32-bit CSRs in LiteX are not really a thing? I am seeing some documentation from quite a while ago that CSRs are 8 bits strided in memory one dword at a time, and I am feeling like it would be nice to have atomic 32-bit loads/stores on CSRs

07:14 <joshua_> but the documentation is quite out of date

07:15 <zyp> I think it's configurable and IIRC the default got changed to 32 years ago

07:15 <joshua_> that is pleasant to know

07:15 <zyp> the CSRs in the stuff I've worked on is certainly 32b

07:18 <joshua_> cool. I shall try it tomorrow

13:40 <mithro> https://antmicro.com/blog/2024/04/simulating-zephyr-based-pcie-devices-warp-pipe/ is pretty cool!

13:40 <tpb> Title: Antmicro · Warp Pipe: library for simulation-driven development of Zephyr and Linux-based PCIe devices (at antmicro.com)