FFY00_ has quit [Remote host closed the connection]
FFY00_ has joined #litex
Degi_ has joined #litex
Degi has quit [Ping timeout: 244 seconds]
Degi_ is now known as Degi
lkcl has quit [Ping timeout: 264 seconds]
lkcl has joined #litex
hansfbaier has joined #litex
captain_morgan6 has joined #litex
captain_morgan has quit [Ping timeout: 265 seconds]
captain_morgan6 is now known as captain_morgan
hansfbaier has quit [Quit: WeeChat 2.8]
rozpruwacz has quit [Ping timeout: 256 seconds]
rozpruwacz has joined #litex
Bertl_oO is now known as Bertl_zZ
kgugala has joined #litex
kgugala__ has joined #litex
kgugala_ has quit [Ping timeout: 265 seconds]
kgugala has quit [Ping timeout: 264 seconds]
hansfbaier has joined #litex
frubbl has joined #litex
rozpruwacz1 has joined #litex
<rozpruwacz1>
Hi, I want to start discussion about the bootloader. It seems that the "bios" software is currently the only supported way of bootloading. But the bios software is quite large and thus takes a lot of precious memory inside of FPGA (rom and sram sections). I have an idea to almost completly move the bootloading outside of the FPGA. With help of SPIFlash module I was able to write very simple bootrom to just copy second stage bootloader fro
<rozpruwacz1>
m spi flash to the main ram and boot it (just a simple loop + jump). This solution requires only single memory block in the FPGA. And the only thing I needed to change in the litex was to remove requirement for the sram section pressence (and ofcourse disabled the compile_software switch).
<rozpruwacz1>
would it be ok to remove this sram pressence requirement ?
lkcl has quit [Ping timeout: 260 seconds]
lkcl has joined #litex
frubbl has quit [Quit: Connection closed]
feldim2425 has quit [Ping timeout: 276 seconds]
feldim2425 has joined #litex
<keesj>
hmm I would expect the opposite to happen with the SPI flash module. The code would be compiled compiled to xip and stack/head/bss in sram to something like memory can be initialized
<keesj>
so..I think the ROM might be mostly movable to flash (this is what I was toying with a few days ago for the firmware of the tinyfpga)
<rozpruwacz1>
keesj: sorry I don't follow. what is xip ? Do You mean to run the bootloader directly from SPI flash ? It would be very slow.
<keesj>
XIP indeed execute in place.
<keesj>
what kind of ram are you talking about?
<rozpruwacz1>
the exact scenario that I have is this: minimal boot rom that initializes sdram and copy barebox from flash to sdram (main memory). Then barebox runs from sdram and do whatever is required.
<rozpruwacz1>
and the boot rom does not require any ram, all is done using registers
<rozpruwacz1>
and the boot rom is compiled into the bitstream and is located at reset address
<keesj>
but.. c requires a stack. perhaps it migt be an option to strip the "bios" and keep sram to a mimimum?
<rozpruwacz1>
i;m not using "bios" at all
<rozpruwacz1>
and small, c program, compiled with correct flags does not require stack :)
<keesj>
I kinda understand that just wondering what the actual difference is > smaller , making use of SPI flash to remove the need for the ROM code to load the data
<keesj>
rozpruwacz1: really? like.. doing no methods calls and inlinig everything and using only 4 variables or something similar?
<rozpruwacz1>
but probably it should be written in assembly because there is nothing forcing gcc to not use the stack. If I run out of registers it will silently use the stack.
<keesj>
and currently barebox_start is in sram?
<rozpruwacz1>
BAREBOX_START is the sdram location
<keesj>
well. with xip you can skip the copy to sram but in both cases the functionality for the ROM/BIOS to recover/ upload are gone
<rozpruwacz1>
is the XIP the feature of xilinx ?
<keesj>
no. more a compiler/linker option
<keesj>
basically make the load address of you code to be in SPI range(is the code is not position indepenent)
<rozpruwacz1>
ok, I get it. I just never heard of this term :)
<keesj>
micro controllers with flash will use this term
<rozpruwacz1>
yeah, I'm using stm32 and avr a lot and never spot on this :D
<keesj>
sometimes the code will still be resonably fast because of caches
<rozpruwacz1>
with barebox running in sram I can update its image located in flash from the barebox. I gues I could put the first stage to FLASH/XIP and load barebox to sram. That way I can eliminate both rom and sram from the FPGA
<keesj>
I think keeping sram is wise, you could move your "ROM" code to the flash (to even copy itself to sram). the main problem I see is that if you wrongly flash your barebox/end up in a reboot loop it would be nice to be able to recover from that(possibly havind a second loader.. like bios in flash)
<keesj>
but.. well.. it would be interesting to see if you can pull it off.. I think older raspberry pi also have a multi stage loader. In my work.. there is always some ROM (even if they don't tell about it) and always some sram.
<rozpruwacz1>
I gues that three (at least three) stage bootloading is the standard.
<keesj>
in real life hardcoding ram parameters or only be able to boot that way might be sub optimal
<rozpruwacz1>
I could add to my boot rom the loading from serial :) That could solve the broken second stage problem
<keesj>
how much sram do you currently need?
<keesj>
but you would still need to load to some place
<rozpruwacz1>
hmm, I think that because of the nature of soft core processors, the "hardcoded" addresses are not really hardcoded.
<rozpruwacz1>
load to offschip sdram
<rozpruwacz1>
*offchip
<keesj>
I can see that working.. how big is the current rom and sram? because this is what you are talking about (making this smaller and less bloated)
<rozpruwacz1>
which current ?? :) my current or litex current ?
<rozpruwacz1>
in litex i think it was 32k rom and and 8k ram making 40 memory blocks out of 66 in my fpga
<rozpruwacz1>
noo, to much
<rozpruwacz1>
somethink is wrong here, I need to check it :)
<rozpruwacz1>
hmm, ok I was right. 40/66 mem block. And in my solution only 1 mem block. So more than a half of fpga memory is used for the rom/ram.
<keesj>
dramatic improvement:P
<keesj>
does your core have cpu cach?
<rozpruwacz>
Yes
<_florent_>
rozpruwacz: The BIOS is convenient as a generic/simple bootloader, but we could try to provide a very minimal version
<_florent_>
rozpruwacz: On FPGA without enough BlockRams, we are executing it directly from Flash (XIP as keesj stated), that's done for example on the Fomu or iCEBreaker targets
<_florent_>
rozpruwacz: But it's indeed also possible to just use your own ROM code, do you see limitations with the current code that prevent you from removing the SRAM?
<_florent_>
the BIOS is in BlockRAM by default since that's the easiest to start with: both Gateware + Software in the bitstream
<rozpruwacz1>
_florent_: currently the SRAM cannot be removed because of "if "sram" not in self.bus.regions.keys()" in litex/soc/integration/soc.py:do_finalize
<rozpruwacz1>
emoticon not intended ...
<_florent_>
rozpruwacz1: ok, I'll try to remove this limitation
<_florent_>
RaivisR__: you FPGA is probably full, routing time can be exponential in this case. You can probably reduce resource usage a bit, this will save more time than upgrading you config :)
<RaivisR__>
yeah, I figured I was being stupid with memory config
pepijndevos has quit [Excess Flood]
<_florent_>
A nice way to speed up P&R for quick iterations with SoC with CPU with LiteX can be to switch to SERV with --cpu-type=serv or use the Minimal variant of VexRiscv: --cpu-variant=minimal