Thursday, 2021-03-18

*** tpb has joined #litex00:00
*** TMM has quit IRC00:19
*** TMM has joined #litex00:19
*** lf has quit IRC00:44
*** lf has joined #litex00:45
*** FFY00_ has quit IRC02:00
*** FFY00_ has joined #litex02:03
*** Degi_ has joined #litex02:45
*** Degi has quit IRC02:46
*** Degi_ is now known as Degi02:46
*** lkcl has quit IRC04:40
*** lkcl has joined #litex04:53
*** hansfbaier has joined #litex04:59
*** captain_morgan6 has joined #litex06:04
*** captain_morgan has quit IRC06:05
*** captain_morgan6 is now known as captain_morgan06:05
*** hansfbaier has quit IRC06:09
*** rozpruwacz has quit IRC06:20
*** rozpruwacz has joined #litex06:40
*** Bertl_oO is now known as Bertl_zZ07:28
*** kgugala has joined #litex08:16
*** kgugala__ has joined #litex08:19
*** kgugala_ has quit IRC08:19
*** kgugala has quit IRC08:21
*** hansfbaier has joined #litex08:25
*** hansfbaier has quit IRC08:25
*** frubbl has joined #litex08:26
*** rozpruwacz1 has joined #litex08:57
rozpruwacz1Hi, 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 fro09:07
rozpruwacz1m 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
rozpruwacz1would it be ok to remove this sram pressence requirement ?09:08
*** lkcl has quit IRC09:10
*** lkcl has joined #litex09:24
*** frubbl has quit IRC09:50
*** feldim2425 has quit IRC09:55
*** feldim2425 has joined #litex10:02
keesjhmm 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 initialized10:03
keesjso..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
rozpruwacz1keesj: 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
keesjXIP indeed execute in place.10:23
keesjwhat kind of ram are you talking about?10:24
rozpruwacz1the 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
rozpruwacz1and the boot rom does not require any ram, all is done using registers10:28
rozpruwacz1and the boot rom is compiled into the bitstream and is located at reset address10:30
keesjbut.. c requires a stack. perhaps it migt be an option to strip the "bios" and keep sram to a mimimum?10:32
rozpruwacz1i;m not using "bios" at all10:34
rozpruwacz1and small, c program, compiled with correct flags does not require stack :)10:35
keesjI 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 data10:35
keesjrozpruwacz1: really? like.. doing no methods calls and inlinig everything and using only 4 variables or something similar?10:38
rozpruwacz1yeah10:38
rozpruwacz1https://pastebin.com/fKNtFEUS10:41
tpbTitle: #include "sdram_phy.h"volatile char* UART_RXTX = (char *)0xf0001000;volati - Pastebin.com (at pastebin.com)10:41
rozpruwacz1and the sdram_phy.h: https://pastebin.com/uHLHLR0e10:42
tpbTitle: #ifndef __SDRAM_PHY_H#define __SDRAM_PHY_H#define DFII_CONTROL_SEL - Pastebin.com (at pastebin.com)10:42
rozpruwacz1I have even print :D10:42
keesjwow10:42
keesjnice10:46
rozpruwacz1but 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
keesjand currently barebox_start is in sram?10:46
rozpruwacz1BAREBOX_START is the sdram location10:47
keesjwell. with xip you can skip the copy to sram but in both cases the functionality for the ROM/BIOS to recover/ upload are gone10:49
rozpruwacz1is the XIP the feature of xilinx ?10:50
keesjno. more a compiler/linker option10:50
keesjbasically make the load address of you code to be in SPI range(is the code is not position indepenent)10:52
keesjhttps://github.com/kekiefer/tinyfpga-litex/blob/master/firmware/linker-xip.ld the .text section is in user_flash10:53
rozpruwacz1ok, I get it. I just never heard of this term :)10:54
keesjmicro controllers with flash will use this term10:54
rozpruwacz1yeah, I'm using stm32 and avr a lot and never spot on this :D10:56
keesjsometimes the code will still be resonably fast because of caches10:57
rozpruwacz1with 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 FPGA11:01
keesjI 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
keesjbut.. 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
rozpruwacz1I gues that three (at least three) stage bootloading is the standard.11:27
keesjin real life hardcoding ram parameters or only be able to boot that way might be sub optimal11:28
rozpruwacz1I could add to my boot rom the loading from serial :) That could solve the broken second stage problem11:28
keesjhow much sram do you currently need?11:28
keesjbut you would still need to load to some place11:29
rozpruwacz1hmm, I think that because of the nature of soft core processors, the "hardcoded" addresses are not really hardcoded.11:29
rozpruwacz1load to offschip sdram11:30
rozpruwacz1*offchip11:30
keesjI 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
rozpruwacz1which current ?? :) my current or litex current ?11:32
rozpruwacz1in litex i think it was 32k rom and and 8k ram making 40 memory blocks out of 66 in my fpga11:34
rozpruwacz1noo, to much11:35
rozpruwacz1somethink is wrong here, I need to check it :)11:39
rozpruwacz1hmm, 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
keesjdramatic improvement:P11:56
keesjdoes your core have cpu cach?11:56
rozpruwaczYes12:08
_florent_rozpruwacz: The BIOS is convenient as a generic/simple bootloader, but we could try to provide a very minimal version13: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 targets13: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 bitstream13: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_finalize13:10
rozpruwacz1emoticon not intended ...13:10
_florent_rozpruwacz1: ok, I'll try to remove this limitation13:13
rozpruwacz1thanks13:16
_florent_https://github.com/enjoy-digital/litex/issues/85513:18
_florent_I'll try to look at it today or tomorrow13:18
_florent_(while also looking at the IRQ)13:18
*** rj_ has joined #litex14:17
*** Bertl_zZ is now known as Bertl14:23
*** rj_ has quit IRC14:42
*** rj_ has joined #litex14:42
RaivisR__hmm, left it routing the design in the morning, came back from dayjob and it´s still routing15:20
*** RaivisR__ is now known as RaivisR15:20
RaivisRdoubling the ram and upgrading hdd to ssd tomorrow, I hope that will help15:25
RaivisRat least a little15:25
*** RaivisR_ has joined #litex15:31
*** RaivisR has quit IRC15:34
*** RaivisR__ has joined #litex15:58
*** RaivisR_ has quit IRC16:02
*** Bertl is now known as Bertl_oO16:26
*** rozpruwacz1 has quit IRC16:29
*** rozpruwacz has quit IRC16:35
*** rozpruwacz has joined #litex16:54
keesjRaivisR__: we all love more RAM and SSD17: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/d0c4199096b4da074068be72a7547b3b6775f23c18: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 config18:15
*** pepijndevos has quit IRC18: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=minimal18:17
*** pepijndevos has joined #litex18:17
*** RaivisR__ is now known as RaivisR18:18
_florent_ex: https://twitter.com/enjoy_digital/status/130078763928148787318:18
RaivisReverything is nice until i try to add ddr3 to the mix, but enough fooling around for today18: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#L2318:21
gatecatin any case litedram + a basic SoC shouldn't be any trouble to route on a ECP5-85F18:22
*** nickoe has quit IRC18:25
*** nickoe has joined #litex18:25
_florent_indeed, it should be very similar to the Trellisboard18:26
_florent_was just not sure if the ECP5 VIP was a 45F or 85F18:26
*** rj_ has quit IRC20:20
*** st-gourichon-fid has quit IRC21:02
*** st-gourichon-fid has joined #litex21:03
*** kgugala has joined #litex21:14
*** kgugala__ has quit IRC21:18
*** cr1901_modern1 has joined #litex21:22
*** cr1901_modern has quit IRC21:25
*** peeps[zen] has joined #litex21:30
*** peepsalot has quit IRC21:30
*** peeps[zen] is now known as peepsalot21:30
*** rozpruwacz1 has joined #litex21:47
*** pdp7 has quit IRC22:08
*** pdp7 has joined #litex22:08
*** cr1901_modern1 has quit IRC22:10
*** cr1901_modern has joined #litex22:10
*** peeps[zen] has joined #litex22:30
*** peepsalot has quit IRC22:32
*** pftbest has quit IRC22:45
*** pftbest has joined #litex23:06
*** pftbest has quit IRC23:11
*** pftbest has joined #litex23:19
*** pftbest has joined #litex23:20
*** pftbest has quit IRC23:24
*** rozpruwacz1 has quit IRC23:26

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!