| *** tpb has joined #timvideos | 00:00 | |
| xobs | Also, 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 |
|---|---|---|
| xobs | fomu_evt is taking the 48 MHz oscillator clock and running it through a pll to divide it down to 16 MHz. | 00:03 |
| mithro | xobs: 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 |
| mithro | xobs: Can you push what you have working somewhere so I can look at it? | 00:05 |
| xobs | the bios is pretty huge. 1 kB is dedicated just to crc32 tables, for example. | 00:05 |
| *** TheAssassin has quit IRC | 00:07 | |
| mithro | xobs: On the ice40up5k, we could load a BIOS and then copy the firmware into SPRAM and jump to that? | 00:09 |
| xobs | mithro: 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 |
| xobs | Also, 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 #timvideos | 00:12 | |
| mithro | single spi block? | 00:17 |
| xobs | I'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 |
| xobs | That's required because of how the ICE40 reset block works. I think. Still not entirely clear on that one. | 00:19 |
| xobs | If the user has a program following the bootloader, then we can't use XIP to stick extra code there. | 00:19 |
| xobs | Granted, the reset block supports four different offsets, so there's probably a workaround. | 00:20 |
| xobs | Still working on packaging stuff up for you.... | 00:25 |
| xobs | Okay, I'm not sure if this'll work or not, but: https://github.com/xobs/litex-buildenv/tree/fomu-evt | 00:50 |
| tpb | Title: GitHub - xobs/litex-buildenv at fomu-evt (at github.com) | 00:50 |
| mithro | xobs: I'm currently rewriting the CPU interface to be based around a single buffer ram and a couple of pointers | 02:20 |
| xobs | mithro: useful! will that reduce the gate count at all? | 02:21 |
| mithro | xobs: Unclear at the moment | 02:21 |
| *** Kripton has quit IRC | 02:37 | |
| xobs | mithro: 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 |
| mithro | xobs: Well, 32.15MHz is better than mine | 02:56 |
| mithro | Going to get dinner | 02:56 |
| xobs | enjoy | 02:56 |
| xobs | I got distracted writing a C program that does bram replacement. | 02:56 |
| cr1901_modern | xobs: I'm sorry! I'm working on it lmao | 02:59 |
| xobs | cr1901_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 #timvideos | 03:00 | |
| cr1901_modern | xobs: 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 tool | 03:01 |
| xobs | Well, 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 target | 03:05 |
| cr1901_modern | along 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 too | 03:07 |
| cr1901_modern | when 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 BIOS | 03:08 |
| cr1901_modern | or whatever you put there | 03:08 |
| xobs | cr1901_modern: https://github.com/xobs/ice40-repack I combined icebram and icepack into one program does all of the unpacking/patching/repacking. | 03:42 |
| tpb | Title: GitHub - xobs/ice40-repack: Repack an ICE40 bitstream image with new memory contents (at github.com) | 03:42 |
| 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 |
| mithro | cr1901_modern: Your confusing the firmware and the bios steps there | 03:50 |
| *** rohitksingh_work has joined #timvideos | 03:51 | |
| cr1901_modern | mithro: What I wanted was a way to completely remove the BIOS from the equation; instead we jump straight to the payload. >> | 03:56 |
| cr1901_modern | I think this is what xobs wants for the fomu bootloader | 03:56 |
| cr1901_modern | xobs: Feel free to correct me if I misunderstand | 03:56 |
| mithro | cr1901_modern: You can already do that? | 03:56 |
| cr1901_modern | mithro: How? :P | 03:56 |
| mithro | cr1901_modern: Just configure your SoC to jump somewhere? | 03:56 |
| xobs | mithro: how? yes. | 03:56 |
| mithro | xobs: Exactly like how we do the BIOS in SPI flash? | 03:57 |
| cr1901_modern | The 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 |
| xobs | mithro: but I want the program to be in BRAM, at address 0. | 03:58 |
| mithro | integrated_rom = 0 | 03:58 |
| cr1901_modern | mithro: Wait wait wait... I can already see the confusion arising. We are talking about two different things I think. | 03:58 |
| cr1901_modern | mithro: First off, I wasn't aware that litex allowed you to "append" a payload into bram | 03:59 |
| mithro | self.submodules.firmware_ram = firmware.FirmwareROM(firmware_ram_size, firmware_filename) | 03:59 |
| cr1901_modern | When did we get that ._.? | 04:00 |
| xobs | And where is it documented? | 04:00 |
| mithro | Jan 26, 2016 apparently | 04:00 |
| mithro | https://github.com/timvideos/litex-buildenv/blob/master/gateware/firmware.py | 04:01 |
| tpb | Title: litex-buildenv/firmware.py at master · timvideos/litex-buildenv · GitHub (at github.com) | 04:01 |
| cr1901_modern | I... NEVER knew about this | 04:01 |
| mithro | cr1901_modern: You have even modified the file apparent :-P | 04:02 |
| cr1901_modern | that being said, that doesn't help when you want to compile the firmware at the same time as libbase, libcompiler_rt | 04:02 |
| cr1901_modern | mithro: That was a grep | 04:02 |
| cr1901_modern | err sed replace | 04:02 |
| mithro | https://github.com/timvideos/litex-buildenv/blob/master/targets/sim/base.py#L35-L39 | 04:02 |
| tpb | Title: litex-buildenv/base.py at master · timvideos/litex-buildenv · GitHub (at github.com) | 04:02 |
| mithro | cr1901_modern: What do you mean? The firmware is always compiled at the same time as libbase / libcompiler_rt | 04:02 |
| mithro | https://github.com/timvideos/litex-buildenv/blob/master/make.py#L137-L147 | 04:03 |
| tpb | Title: litex-buildenv/make.py at master · timvideos/litex-buildenv · GitHub (at github.com) | 04:03 |
| xobs | mithro: not always. I'm using tinyusb as the firmware, and that gets built separately. | 04:03 |
| mithro | xobs: That is us working /around/ the way the system normally works | 04:03 |
| cr1901_modern | mithro: the constructor for FirmwareROM runs immediately. Which means your firmware file must already exist. | 04:03 |
| cr1901_modern | i.e. if your firmware file doesn't already exist from a previous compile, trying to instantiate FirmwareROM will fail | 04:03 |
| mithro | cr1901_modern: That is why https://github.com/timvideos/litex-buildenv/blob/master/gateware/firmware.py#L33-L36 exists | 04:04 |
| tpb | Title: litex-buildenv/firmware.py at master · timvideos/litex-buildenv · GitHub (at github.com) | 04:04 |
| cr1901_modern | Hmmmm | 04:06 |
| cr1901_modern | My 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_modern | just the directory, which then gets added the the Builder class (and replaces the bios.bin in initialize_rom) | 04:07 |
| mithro | cr1901_modern: That is exactly how it works? | 04:08 |
| cr1901_modern | https://github.com/timvideos/litex-buildenv/blob/master/targets/sim/base.py#L35-L39 Let's look at this example again | 04:10 |
| tpb | Title: litex-buildenv/base.py at master · timvideos/litex-buildenv · GitHub (at github.com) | 04:10 |
| cr1901_modern | the SoC constructor runs before the Builder class | 04:11 |
| cr1901_modern | https://github.com/timvideos/litex-buildenv/blob/master/make.py#L123 | 04:11 |
| tpb | Title: litex-buildenv/make.py at master · timvideos/litex-buildenv · GitHub (at github.com) | 04:11 |
| cr1901_modern | https://github.com/timvideos/litex-buildenv/blob/master/make.py#L136 | 04:11 |
| tpb | Title: litex-buildenv/make.py at master · timvideos/litex-buildenv · GitHub (at github.com) | 04:11 |
| cr1901_modern | The Builder class is where _all_ the software is compiled | 04:11 |
| cr1901_modern | So if your custom firmware image doesn't already exist by the time you instantiate a SoC, you error out >> | 04:12 |
| cr1901_modern | https://github.com/timvideos/litex-buildenv/blob/master/gateware/firmware.py#L33-L36 | 04:12 |
| tpb | Title: litex-buildenv/firmware.py at master · timvideos/litex-buildenv · GitHub (at github.com) | 04:12 |
| cr1901_modern | My 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_rt | 04:13 |
| mithro | cr1901_modern: Try it | 04:14 |
| xobs | mithro: that doesn't work. "migen.fhdl.module.FinalizeError: CPU needs a rom to be registered with SoC.register_mem()" | 04:15 |
| xobs | Or is there something else I need to do to register the FirmwareROM with the soc? | 04:17 |
| mithro | xobs: Did you do this -> https://github.com/timvideos/litex-buildenv/blob/master/targets/mimasv2/base.py#L223-L226 | 04:17 |
| tpb | Title: litex-buildenv/base.py at master · timvideos/litex-buildenv · GitHub (at github.com) | 04:17 |
| mithro | xobs: basically follow https://github.com/timvideos/litex-buildenv/blob/master/targets/mimasv2/base.py#L223-L226 and replace spiflash with the firmware rom | 04:17 |
| tpb | Title: litex-buildenv/base.py at master · timvideos/litex-buildenv · GitHub (at github.com) | 04:17 |
| cr1901_modern | xobs: The CPU _must_ have a memory region called ROM | 04:17 |
| cr1901_modern | I think that's a misoc holdover? | 04:18 |
| cr1901_modern | err "rom" | 04:18 |
| xobs | Okay, how do I map FirmwareROM to that region? | 04:18 |
| cr1901_modern | self.register_rom(self.firmware_ram.bus, firmware_ram_size) | 04:18 |
| xobs | cr1901_modern: I need to do self.register_rom() and self.add_memory_region("rom", ...)? | 04:20 |
| cr1901_modern | register_rom internally calls add_memory_region | 04:21 |
| cr1901_modern | it's a convenience method | 04:21 |
| mithro | xobs: You only need the add_memory_region if you use self.register_mem instead of self.register_rom | 04:21 |
| mithro | xobs: 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_modern | Incidentally, https://github.com/timvideos/litex-buildenv/blob/master/targets/sim/base.py, this file does _not_ call self.register_mem :) | 04:22 |
| cr1901_modern | err sorry | 04:22 |
| cr1901_modern | ignore me | 04:22 |
| mithro | https://github.com/timvideos/litex-buildenv/blob/master/targets/sim/base.py#L51 | 04:23 |
| tpb | Title: litex-buildenv/base.py at master · timvideos/litex-buildenv · GitHub (at github.com) | 04:23 |
| cr1901_modern | mithro: I meant add_memory_region* | 04:23 |
| xobs | Somehow, that approach eats up 7% (~400) more gates. | 04:25 |
| mithro | xobs: Than? | 04:25 |
| xobs | mithro: than letting litex generate the rom and filling it with random data. | 04:26 |
| mithro | xobs: Something is fishy there | 04:27 |
| xobs | Oh I bet that's it -- FirmwareROM is read-write, whereas `integrated_rom_size` sets read_only=True | 04:30 |
| mithro | xobs: I think it's more likely something to do with the addressing? | 04:30 |
| cr1901_modern | mithro: I can't build the sim target, as litex doesn't have it anymore | 04:31 |
| cr1901_modern | but I still don't see how if the firmware image doesn't exist apriori, it'll be built when the Builder runs | 04:31 |
| cr1901_modern | (not to mention, doesn't the sim target still have a BIOS?) | 04:31 |
| xobs | Okay, thank you mithro , that actually works and does what I was trying to do. | 04:35 |
| xobs | And yeah, setting read_only=True drops the ICESTORM_LC count from 5099 down to 4715. | 04:36 |
| mithro | xobs: Interesting, I wonder why... | 04:36 |
| cr1901_modern | transparent read port, most likely | 04:36 |
| xobs | Okay, and I can still patch the random data with bios.bin. | 04:38 |
| cr1901_modern | xobs: 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 |
| xobs | cr1901_modern: it does use libbase and friends, but it's built after the fact. | 04:39 |
| xobs | for testing right now, I'm actually replacing the garbage data in BRAM with bios.bin. | 04:40 |
| cr1901_modern | hmmm | 04:41 |
| xobs | Let 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 it | 04:42 |
| cr1901_modern | Okay, 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_modern | It won't error out, but the RAM will be blank | 04:43 |
| mithro | cr1901_modern: Did you look at the code I linked? | 04:43 |
| cr1901_modern | mithro: I can't run it | 04:43 |
| cr1901_modern | boards.sim no longer exists | 04:43 |
| cr1901_modern | mithro: Oh, I see that the firmware ROM creates an empty wishbone RAM | 04:43 |
| xobs | This is what I've got: https://github.com/xobs/litex-buildenv/blob/fomu-evt/targets/fomu_evt/base.py#L29 | 04:44 |
| tpb | Title: litex-buildenv/base.py at fomu-evt · xobs/litex-buildenv · GitHub (at github.com) | 04:44 |
| cr1901_modern | mithro: okay fair enough. But that fresh wishbone RAM won't be populated when Builder.build() runs, correct? | 04:44 |
| cr1901_modern | i.e. you have to regenerate the gateware _after_ you've build all the firmware to populate firmware ROM | 04:45 |
| mithro | https://github.com/xobs/litex-buildenv/blob/fomu-evt/Makefile#L295-L302 | 04:47 |
| tpb | Title: litex-buildenv/Makefile at fomu-evt · xobs/litex-buildenv · GitHub (at github.com) | 04:47 |
| xobs | Ooh, 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_modern | Actually, come to think of it... what the hell does this line do? https://github.com/timvideos/litex-buildenv/blob/master/gateware/firmware.py#L38 | 04:48 |
| tpb | Title: litex-buildenv/firmware.py at master · timvideos/litex-buildenv · GitHub (at github.com) | 04:48 |
| cr1901_modern | I've never used __class__ before | 04:48 |
| cr1901_modern | mithro: 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_modern | If you run "make firmware", that'll ensure everything is up to date before building the gateware. | 04:55 |
| cr1901_modern | And well, in principle, so will "make gateware". Except for that one edge case where you manually specify using a FirmwareROM :/. | 04:55 |
| cr1901_modern | And that bugs me :P | 04:55 |
| xobs | Does 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 |
| xobs | Answer: 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/ close | 07:52 |
| *** swalladge_ has joined #timvideos | 08:07 | |
| *** swalladge has quit IRC | 08:08 | |
| *** cr1901_modern has quit IRC | 08:27 | |
| *** Kripton has quit IRC | 08:33 | |
| *** Kripton has joined #timvideos | 09:00 | |
| *** swalladge_ is now known as swalladge | 10:06 | |
| *** paddatrapper has quit IRC | 10:55 | |
| *** paddatrapper has joined #timvideos | 10:55 | |
| *** rohitksingh_work has quit IRC | 12:11 | |
| *** rohitksingh_work has joined #timvideos | 12:13 | |
| *** rohitksingh_work has quit IRC | 12:45 | |
| *** Kripton has quit IRC | 13:29 | |
| *** Kripton has joined #timvideos | 13:30 | |
| *** sb0_ has joined #timvideos | 14:00 | |
| *** sb0_ has quit IRC | 14:45 | |
| *** cr1901_modern has joined #timvideos | 15:05 | |
| *** CarlFK has quit IRC | 16:04 | |
| *** rohitksingh has joined #timvideos | 16:09 | |
| mithro | xobs: No, it doesn't let you specify multiple clock domains without using the Python API yet | 16:44 |
| mithro | xobs: What did you change to get to 45.22MHz? | 16:45 |
| *** ZipCPU has left #timvideos | 16:54 | |
| *** CarlFK has joined #timvideos | 17:10 | |
| *** ChanServ sets mode: +v CarlFK | 17:10 | |
| *** rohitksingh has quit IRC | 17:15 | |
| *** Kripton has quit IRC | 20:08 | |
| *** Kripton has joined #timvideos | 20:30 | |
| CarlFK | xobs: mithro: https://www.crowdsupply.com/img/cd50/fomu-evt-1_jpg_project-body.jpg has tomu.im/fomu-evt1/ printed on it, but https://tomu.im/fomu-evt1/ is 404 | 21:11 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
