Thursday, 2018-12-20

*** tpb has joined #timvideos00:00
xobsAlso, I've increased BRAM to 11264 bytes, and I load the USB test code as a bios.  That way it's all self-contained and I just need to use `fomu-flasher -f top.bin` to run the program.00:02
xobsfomu_evt is taking the 48 MHz oscillator clock and running  it through a pll to divide it down to 16 MHz.00:03
mithroxobs: I'm a bit confused why the BIOS is so huge even with LTO on - the USB test code seems to be quite a lot smaller...00:04
mithroxobs: Can you push what you have working somewhere so I can look at it?00:05
xobsthe bios is pretty huge.  1 kB is dedicated just to crc32 tables, for example.00:05
*** TheAssassin has quit IRC00:07
mithroxobs: On the ice40up5k, we could load a BIOS and then copy the firmware into SPRAM and jump to that?00:09
xobsmithro: we could, and that was my initial approach, except I ran into two problems: first I was accidentally overwriting the BIOS RAM when doing a serialboot, and second I was having all sorts of trouble with memory load offsets being incorrect.00:11
xobsAlso, for the final image we'll want it to be completely self-contained so it fits in a single SPI block.00:12
*** TheAssassin has joined #timvideos00:12
mithrosingle spi block?00:17
xobsI'm thinking about the bootloader.  It would make sense for it to be much like Tomu, in that it's self-contained.  When a user loads a program onto Fomu, they load it immediately following the bootloader.00:18
xobsThat's required because of how the ICE40 reset block works.  I think.  Still not entirely clear on that one.00:19
xobsIf the user has a program following the bootloader, then we can't use XIP to stick extra code there.00:19
xobsGranted, the reset block supports four different offsets, so there's probably a workaround.00:20
xobsStill working on packaging stuff up for you....00:25
xobsOkay, I'm not sure if this'll work or not, but:
tpbTitle: GitHub - xobs/litex-buildenv at fomu-evt (at
mithroxobs: I'm currently rewriting the CPU interface to be based around a single buffer ram and a couple of pointers02:20
xobsmithro: useful! will that reduce the gate count at all?02:21
mithroxobs: Unclear at the moment02:21
*** Kripton has quit IRC02:37
xobsmithro: Oh, I see, it's not actually meeting timing, I just don't know how to specify the desired speed: "Info: Max frequency for clock 'usb_48_clk_$glb_clk': 32.15 MHz (PASS at 16.00 MHz)"02:55
mithroxobs: Well, 32.15MHz is better than mine02:56
mithroGoing to get dinner02:56
xobsI got distracted writing a C program that does bram replacement.02:56
cr1901_modernxobs: I'm sorry! I'm working on it lmao02:59
xobscr1901_modern: no, it's okay. I incorporated icepack and icebram, so now I can give it a source top.bin and mem.init, and specify a replacement BIOS image, and it'll do everything in one program.02:59
*** Kripton has joined #timvideos03:00
cr1901_modernxobs: That works, but I still think I'm going to go with the Makefile approach for my method; from what I can tell in the other FOSS FPGA projects going on, bram replacement will be a separate tool03:01
xobsWell, as of right now the only change that needs to be made in litex is to generate a completely full, completely random BIOS image.  Or use the output if "icebram" to generate it.  Is it safe to say the FIRMWARE= parameter does that?03:02
cr1901_modern"FIRMWARE=micropython" is special. I was proposing "FIRMWARE=bram-init" as a special target03:05
cr1901_modernalong w/ an accompanying shell script which runs icebram instead of gcc flow to create a firmware image. It might need access to the ROM size too03:07
cr1901_modernwhen you just want to swap out firmware, you run "make bram-reload". That'll run the firmware target and then replace your currently active firmware (defined by the FIRMWARE variable) by injecting the bram-init firmware with your BIOS03:08
cr1901_modernor whatever you put there03:08
xobscr1901_modern: I combined icebram and icepack into one program does all of the unpacking/patching/repacking.03:42
tpbTitle: GitHub - xobs/ice40-repack: Repack an ICE40 bitstream image with new memory contents (at
cr1901_modern_florent_/mithro: I've been talking this over w/ xobs... I think litex/litex-buildenv should have a "power user" option to completely override the bios image during the firmware compilation step. Not just a priori to compilation (via soc.initialize_rom())03:49
mithrocr1901_modern: Your confusing the firmware and the bios steps there03:50
*** rohitksingh_work has joined #timvideos03:51
cr1901_modernmithro: What I wanted was a way to completely remove the BIOS from the equation; instead we jump straight to the payload. >>03:56
cr1901_modernI think this is what xobs wants for the fomu bootloader03:56
cr1901_modernxobs: Feel free to correct me if I misunderstand03:56
mithrocr1901_modern: You can already do that?03:56
cr1901_modernmithro: How? :P03:56
mithrocr1901_modern: Just configure your SoC to jump somewhere?03:56
xobsmithro: how? yes.03:56
mithroxobs: Exactly like how we do the BIOS in SPI flash?03:57
cr1901_modernThe way I understand LiteX's build logic is: If you provide your own struct.pack image ahead of time, litex will use that as the BRAM payload.03:57
xobsmithro: but I want the program to be in BRAM, at address 0.03:58
mithrointegrated_rom = 003:58
cr1901_modernmithro: Wait wait wait... I can already see the confusion arising. We are talking about two different things I think.03:58
cr1901_modernmithro: First off, I wasn't aware that litex allowed you to "append" a payload into bram03:59
mithro self.submodules.firmware_ram = firmware.FirmwareROM(firmware_ram_size, firmware_filename)03:59
cr1901_modernWhen did we get that ._.?04:00
xobsAnd where is it documented?04:00
mithroJan 26, 2016 apparently04:00
tpbTitle: litex-buildenv/ at master · timvideos/litex-buildenv · GitHub (at
cr1901_modernI... NEVER knew about this04:01
mithrocr1901_modern: You have even modified the file apparent :-P04:02
cr1901_modernthat being said, that doesn't help when you want to compile the firmware at the same time as libbase, libcompiler_rt04:02
cr1901_modernmithro: That was a grep04:02
cr1901_modernerr sed replace04:02
tpbTitle: litex-buildenv/ at master · timvideos/litex-buildenv · GitHub (at
mithrocr1901_modern: What do you mean? The firmware is always compiled at the same time as libbase / libcompiler_rt04:02
tpbTitle: litex-buildenv/ at master · timvideos/litex-buildenv · GitHub (at
xobsmithro: not always. I'm using tinyusb as the firmware, and that gets built separately.04:03
mithroxobs: That is us working /around/ the way the system normally works04:03
cr1901_modernmithro: the constructor for FirmwareROM runs immediately. Which means your firmware file must already exist.04:03
cr1901_moderni.e. if your firmware file doesn't already exist from a previous compile, trying to instantiate FirmwareROM will fail04:03
mithrocr1901_modern: That is why exists04:04
tpbTitle: litex-buildenv/ at master · timvideos/litex-buildenv · GitHub (at
cr1901_modernMy opinion is that if one wants to use libbase, libcompiler_rt, etc in their shiny custom firmware, it should be compiled and linked at the same time as those libraries. I.e. the firmware file shouldn't _have_ to exist.04:07
cr1901_modernjust the directory, which then gets added the the Builder class (and replaces the bios.bin in initialize_rom)04:07
mithrocr1901_modern: That is exactly how it works?04:08
cr1901_modern Let's look at this example again04:10
tpbTitle: litex-buildenv/ at master · timvideos/litex-buildenv · GitHub (at
cr1901_modernthe SoC constructor runs before the Builder class04:11
tpbTitle: litex-buildenv/ at master · timvideos/litex-buildenv · GitHub (at
tpbTitle: litex-buildenv/ at master · timvideos/litex-buildenv · GitHub (at
cr1901_modernThe Builder class is where _all_ the software is compiled04:11
cr1901_modernSo if your custom firmware image doesn't already exist by the time you instantiate a SoC, you error out >>04:12
tpbTitle: litex-buildenv/ at master · timvideos/litex-buildenv · GitHub (at
cr1901_modernMy question is: What if you wanted to build your shiny firmware _and_ replace the BIOS, _and_ build your firmware at the same time as the support libraries, like libbase, libcompiler_rt04:13
mithrocr1901_modern: Try it04:14
xobsmithro: that doesn't work.  "migen.fhdl.module.FinalizeError: CPU needs a rom to be registered with SoC.register_mem()"04:15
xobsOr is there something else I need to do to register the FirmwareROM with the soc?04:17
mithroxobs: Did you do this ->
tpbTitle: litex-buildenv/ at master · timvideos/litex-buildenv · GitHub (at
mithroxobs: basically follow and replace spiflash with the firmware rom04:17
tpbTitle: litex-buildenv/ at master · timvideos/litex-buildenv · GitHub (at
cr1901_modernxobs: The CPU _must_ have a memory region called ROM04:17
cr1901_modernI think that's a misoc holdover?04:18
cr1901_modernerr "rom"04:18
xobsOkay, how do I map FirmwareROM to that region?04:18
cr1901_modernself.register_rom(self.firmware_ram.bus, firmware_ram_size)04:18
xobscr1901_modern: I need to do self.register_rom() and self.add_memory_region("rom", ...)?04:20
cr1901_modernregister_rom internally calls add_memory_region04:21
cr1901_modernit's a convenience method04:21
mithroxobs: You only need the add_memory_region if you use         self.register_mem instead of self.register_rom04:21
mithroxobs: Which you want to do if you want to combined the firmware+sram regions together into a "ram with initial contents" type thing....04:22
cr1901_modernIncidentally,, this file does _not_ call self.register_mem :)04:22
cr1901_modernerr sorry04:22
cr1901_modernignore me04:22
tpbTitle: litex-buildenv/ at master · timvideos/litex-buildenv · GitHub (at
cr1901_modernmithro: I meant add_memory_region*04:23
xobsSomehow, that approach eats up 7% (~400) more gates.04:25
mithroxobs: Than?04:25
xobsmithro: than letting litex generate the rom and filling it with random data.04:26
mithroxobs: Something is fishy there04:27
xobsOh I bet that's it -- FirmwareROM is read-write, whereas `integrated_rom_size` sets read_only=True04:30
mithroxobs: I think it's more likely something to do with the addressing?04:30
cr1901_modernmithro: I can't build the sim target, as litex doesn't have it anymore04:31
cr1901_modernbut I still don't see how if the firmware image doesn't exist apriori, it'll be built when the Builder runs04:31
cr1901_modern(not to mention, doesn't the sim target still have a BIOS?)04:31
xobsOkay, thank you mithro , that actually works and does what I was trying to do.04:35
xobsAnd yeah, setting read_only=True drops the ICESTORM_LC count from 5099 down to 4715.04:36
mithroxobs: Interesting, I wonder why...04:36
cr1901_moderntransparent read port, most likely04:36
xobsOkay, and I can still patch the random data with bios.bin.04:38
cr1901_modernxobs: Does your bootloader firmware use libbase and friends at all (or at least the CSR headers)? Are you building it at the same time as the rest of the libraries?04:38
xobscr1901_modern: it does use libbase and friends, but it's built after the fact.04:39
xobsfor testing right now, I'm actually replacing the garbage data in BRAM with bios.bin.04:40
xobsLet me push this so I can show you what I'm working with.04:42
cr1901_modern>(11:07:28 PM) mithro: cr1901_modern: Try it04:42
cr1901_modernOkay, I can't try this in my current setup. So what's supposed to actually happen if the firmware image doesn't exist when you instantiate firmwareROM?04:42
cr1901_modernIt won't error out, but the RAM will be blank04:43
mithrocr1901_modern: Did you look at the code I linked?04:43
cr1901_modernmithro: I can't run it04:43
cr1901_modernboards.sim no longer exists04:43
cr1901_modernmithro: Oh, I see that the firmware ROM creates an empty wishbone RAM04:43
xobsThis is what I've got:
tpbTitle: litex-buildenv/ at fomu-evt · xobs/litex-buildenv · GitHub (at
cr1901_modernmithro: okay fair enough. But that fresh wishbone RAM won't be populated when runs, correct?04:44
cr1901_moderni.e. you have to regenerate the gateware _after_ you've build all the firmware to populate firmware ROM04:45
tpbTitle: litex-buildenv/Makefile at fomu-evt · xobs/litex-buildenv · GitHub (at
xobsOoh, that one went well: "Info: Max frequency for clock 'usb_48_clk_$glb_clk': 36.84 MHz (PASS at 16.00 MHz)"04:48
cr1901_modernActually, come to think of it... what the hell does this line do?
tpbTitle: litex-buildenv/ at master · timvideos/litex-buildenv · GitHub (at
cr1901_modernI've never used __class__ before04:48
cr1901_modernmithro: I mean... that works. I don't like it (should be able to compile the firmware and gateware in one fell swoop, not have to run two separate commands), but that does work.04:54
cr1901_modernIf you run "make firmware", that'll ensure everything is up to date before building the gateware.04:55
cr1901_modernAnd well, in principle, so will "make gateware". Except for that one edge case where you manually specify using a FirmwareROM :/.04:55
cr1901_modernAnd that bugs me :P04:55
xobsDoes nextpnr support multiple clock domains yet? And how do I specify it? I managed to specify 48 MHz for the USB clock, but somehow nextpnr applied that to sys as well...05:31
xobsAnswer: yes it does, but litex doesn't support it yet.  Migen does, however.07:50
xobs"Max frequency for clock 'usb_48_clk_$glb_clk': 45.22 MHz (FAIL at 48.00 MHz)" /so/ close07:52
*** swalladge_ has joined #timvideos08:07
*** swalladge has quit IRC08:08
*** cr1901_modern has quit IRC08:27
*** Kripton has quit IRC08:33
*** Kripton has joined #timvideos09:00
*** swalladge_ is now known as swalladge10:06
*** paddatrapper has quit IRC10:55
*** paddatrapper has joined #timvideos10:55
*** rohitksingh_work has quit IRC12:11
*** rohitksingh_work has joined #timvideos12:13
*** rohitksingh_work has quit IRC12:45
*** Kripton has quit IRC13:29
*** Kripton has joined #timvideos13:30
*** sb0_ has joined #timvideos14:00
*** sb0_ has quit IRC14:45
*** cr1901_modern has joined #timvideos15:05
*** CarlFK has quit IRC16:04
*** rohitksingh has joined #timvideos16:09
mithroxobs: No, it doesn't let you specify multiple clock domains without using the Python API yet16:44
mithroxobs: What did you change to get to 45.22MHz?16:45
*** ZipCPU has left #timvideos16:54
*** CarlFK has joined #timvideos17:10
*** ChanServ sets mode: +v CarlFK17:10
*** rohitksingh has quit IRC17:15
*** Kripton has quit IRC20:08
*** Kripton has joined #timvideos20:30
CarlFKxobs: mithro:  has printed on it, but is 40421:11

Generated by 2.13.1 by Marius Gedminas - find it at!