*** tpb has joined #litex | 00:00 | |
*** TMM has quit IRC | 00:19 | |
*** TMM has joined #litex | 00:19 | |
*** lf has quit IRC | 00:44 | |
*** lf has joined #litex | 00:45 | |
*** FFY00_ has quit IRC | 02:00 | |
*** FFY00_ has joined #litex | 02:03 | |
*** Degi_ has joined #litex | 02:45 | |
*** Degi has quit IRC | 02:46 | |
*** Degi_ is now known as Degi | 02:46 | |
*** lkcl has quit IRC | 04:40 | |
*** lkcl has joined #litex | 04:53 | |
*** hansfbaier has joined #litex | 04:59 | |
*** captain_morgan6 has joined #litex | 06:04 | |
*** captain_morgan has quit IRC | 06:05 | |
*** captain_morgan6 is now known as captain_morgan | 06:05 | |
*** hansfbaier has quit IRC | 06:09 | |
*** rozpruwacz has quit IRC | 06:20 | |
*** rozpruwacz has joined #litex | 06:40 | |
*** Bertl_oO is now known as Bertl_zZ | 07:28 | |
*** kgugala has joined #litex | 08:16 | |
*** kgugala__ has joined #litex | 08:19 | |
*** kgugala_ has quit IRC | 08:19 | |
*** kgugala has quit IRC | 08:21 | |
*** hansfbaier has joined #litex | 08:25 | |
*** hansfbaier has quit IRC | 08:25 | |
*** frubbl has joined #litex | 08:26 | |
*** rozpruwacz1 has joined #litex | 08:57 | |
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 | 09:07 |
---|---|---|
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). | 09:07 |
rozpruwacz1 | would it be ok to remove this sram pressence requirement ? | 09:08 |
*** lkcl has quit IRC | 09:10 | |
*** lkcl has joined #litex | 09:24 | |
*** frubbl has quit IRC | 09:50 | |
*** feldim2425 has quit IRC | 09:55 | |
*** feldim2425 has joined #litex | 10:02 | |
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 | 10:03 |
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) | 10:05 |
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. | 10:16 |
keesj | XIP indeed execute in place. | 10:23 |
keesj | what kind of ram are you talking about? | 10:24 |
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. | 10:27 |
rozpruwacz1 | and the boot rom does not require any ram, all is done using registers | 10:28 |
rozpruwacz1 | and the boot rom is compiled into the bitstream and is located at reset address | 10:30 |
keesj | but.. c requires a stack. perhaps it migt be an option to strip the "bios" and keep sram to a mimimum? | 10:32 |
rozpruwacz1 | i;m not using "bios" at all | 10:34 |
rozpruwacz1 | and small, c program, compiled with correct flags does not require stack :) | 10:35 |
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 | 10:35 |
keesj | rozpruwacz1: really? like.. doing no methods calls and inlinig everything and using only 4 variables or something similar? | 10:38 |
rozpruwacz1 | yeah | 10:38 |
rozpruwacz1 | https://pastebin.com/fKNtFEUS | 10:41 |
tpb | Title: #include "sdram_phy.h"volatile char* UART_RXTX = (char *)0xf0001000;volati - Pastebin.com (at pastebin.com) | 10:41 |
rozpruwacz1 | and the sdram_phy.h: https://pastebin.com/uHLHLR0e | 10:42 |
tpb | Title: #ifndef __SDRAM_PHY_H#define __SDRAM_PHY_H#define DFII_CONTROL_SEL - Pastebin.com (at pastebin.com) | 10:42 |
rozpruwacz1 | I have even print :D | 10:42 |
keesj | wow | 10:42 |
keesj | nice | 10:46 |
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. | 10:46 |
keesj | and currently barebox_start is in sram? | 10:46 |
rozpruwacz1 | BAREBOX_START is the sdram location | 10:47 |
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 | 10:49 |
rozpruwacz1 | is the XIP the feature of xilinx ? | 10:50 |
keesj | no. more a compiler/linker option | 10:50 |
keesj | basically make the load address of you code to be in SPI range(is the code is not position indepenent) | 10:52 |
keesj | https://github.com/kekiefer/tinyfpga-litex/blob/master/firmware/linker-xip.ld the .text section is in user_flash | 10:53 |
rozpruwacz1 | ok, I get it. I just never heard of this term :) | 10:54 |
keesj | micro controllers with flash will use this term | 10:54 |
rozpruwacz1 | yeah, I'm using stm32 and avr a lot and never spot on this :D | 10:56 |
keesj | sometimes the code will still be resonably fast because of caches | 10:57 |
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 | 11:01 |
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) | 11:22 |
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. | 11:26 |
rozpruwacz1 | I gues that three (at least three) stage bootloading is the standard. | 11:27 |
keesj | in real life hardcoding ram parameters or only be able to boot that way might be sub optimal | 11:28 |
rozpruwacz1 | I could add to my boot rom the loading from serial :) That could solve the broken second stage problem | 11:28 |
keesj | how much sram do you currently need? | 11:28 |
keesj | but you would still need to load to some place | 11:29 |
rozpruwacz1 | hmm, I think that because of the nature of soft core processors, the "hardcoded" addresses are not really hardcoded. | 11:29 |
rozpruwacz1 | load to offschip sdram | 11:30 |
rozpruwacz1 | *offchip | 11:30 |
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) | 11:31 |
rozpruwacz1 | which current ?? :) my current or litex current ? | 11:32 |
rozpruwacz1 | in litex i think it was 32k rom and and 8k ram making 40 memory blocks out of 66 in my fpga | 11:34 |
rozpruwacz1 | noo, to much | 11:35 |
rozpruwacz1 | somethink is wrong here, I need to check it :) | 11:39 |
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. | 11:50 |
keesj | dramatic improvement:P | 11:56 |
keesj | does your core have cpu cach? | 11:56 |
rozpruwacz | Yes | 12:08 |
_florent_ | rozpruwacz: The BIOS is convenient as a generic/simple bootloader, but we could try to provide a very minimal version | 13:02 |
_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 | 13:03 |
_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? | 13:04 |
_florent_ | the BIOS is in BlockRAM by default since that's the easiest to start with: both Gateware + Software in the bitstream | 13:06 |
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 | 13:10 |
rozpruwacz1 | emoticon not intended ... | 13:10 |
_florent_ | rozpruwacz1: ok, I'll try to remove this limitation | 13:13 |
rozpruwacz1 | thanks | 13:16 |
_florent_ | https://github.com/enjoy-digital/litex/issues/855 | 13:18 |
_florent_ | I'll try to look at it today or tomorrow | 13:18 |
_florent_ | (while also looking at the IRQ) | 13:18 |
*** rj_ has joined #litex | 14:17 | |
*** Bertl_zZ is now known as Bertl | 14:23 | |
*** rj_ has quit IRC | 14:42 | |
*** rj_ has joined #litex | 14:42 | |
RaivisR__ | hmm, left it routing the design in the morning, came back from dayjob and it´s still routing | 15:20 |
*** RaivisR__ is now known as RaivisR | 15:20 | |
RaivisR | doubling the ram and upgrading hdd to ssd tomorrow, I hope that will help | 15:25 |
RaivisR | at least a little | 15:25 |
*** RaivisR_ has joined #litex | 15:31 | |
*** RaivisR has quit IRC | 15:34 | |
*** RaivisR__ has joined #litex | 15:58 | |
*** RaivisR_ has quit IRC | 16:02 | |
*** Bertl is now known as Bertl_oO | 16:26 | |
*** rozpruwacz1 has quit IRC | 16:29 | |
*** rozpruwacz has quit IRC | 16:35 | |
*** rozpruwacz has joined #litex | 16:54 | |
keesj | RaivisR__: we all love more RAM and SSD | 17:53 |
RaivisR__ | yes we do, first they sent me e-mail stating that ram I chose wasn´t available, then also ssd... | 17:54 |
RaivisR__ | i got totally confused, if ddr3 chip has ¨1Gb¨ density, that is 1 gigabit and not byte, right? | 17:59 |
_florent_ | rozpruwacz: This should fix the GPIOIn IRQ support: https://github.com/enjoy-digital/litex/commit/d0c4199096b4da074068be72a7547b3b6775f23c | 18:07 |
_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 :) | 18:14 |
RaivisR__ | yeah, I figured I was being stupid with memory config | 18:15 |
*** pepijndevos has quit IRC | 18:17 | |
_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 | 18:17 |
*** pepijndevos has joined #litex | 18:17 | |
*** RaivisR__ is now known as RaivisR | 18:18 | |
_florent_ | ex: https://twitter.com/enjoy_digital/status/1300787639281487873 | 18:18 |
RaivisR | everything is nice until i try to add ddr3 to the mix, but enough fooling around for today | 18:18 |
_florent_ | You can reduce LiteDRAM usage a bit (but also performance) by reducing cmd_buffer_depth here: https://github.com/enjoy-digital/litedram/blob/master/litedram/core/controller.py#L23 | 18:21 |
gatecat | in any case litedram + a basic SoC shouldn't be any trouble to route on a ECP5-85F | 18:22 |
*** nickoe has quit IRC | 18:25 | |
*** nickoe has joined #litex | 18:25 | |
_florent_ | indeed, it should be very similar to the Trellisboard | 18:26 |
_florent_ | was just not sure if the ECP5 VIP was a 45F or 85F | 18:26 |
*** rj_ has quit IRC | 20:20 | |
*** st-gourichon-fid has quit IRC | 21:02 | |
*** st-gourichon-fid has joined #litex | 21:03 | |
*** kgugala has joined #litex | 21:14 | |
*** kgugala__ has quit IRC | 21:18 | |
*** cr1901_modern1 has joined #litex | 21:22 | |
*** cr1901_modern has quit IRC | 21:25 | |
*** peeps[zen] has joined #litex | 21:30 | |
*** peepsalot has quit IRC | 21:30 | |
*** peeps[zen] is now known as peepsalot | 21:30 | |
*** rozpruwacz1 has joined #litex | 21:47 | |
*** pdp7 has quit IRC | 22:08 | |
*** pdp7 has joined #litex | 22:08 | |
*** cr1901_modern1 has quit IRC | 22:10 | |
*** cr1901_modern has joined #litex | 22:10 | |
*** peeps[zen] has joined #litex | 22:30 | |
*** peepsalot has quit IRC | 22:32 | |
*** pftbest has quit IRC | 22:45 | |
*** pftbest has joined #litex | 23:06 | |
*** pftbest has quit IRC | 23:11 | |
*** pftbest has joined #litex | 23:19 | |
*** pftbest has joined #litex | 23:20 | |
*** pftbest has quit IRC | 23:24 | |
*** rozpruwacz1 has quit IRC | 23:26 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!