| openpowerbot | [slack] <joel> @Boris Shingarov You're right on the money, there's a bit to switch the mapping in the syscon registers. This controls the dram_at_0 signal in the vhdl. | 06:05 |
|---|---|---|
| openpowerbot | [slack] <joel> | 06:05 |
| openpowerbot | [slack] <joel> I assumed the mapping was flipped before jumping to the application in `microwatt/litedram/gen-src/sdram_init/main.c`, but it doesn't look like we do. | 06:05 |
| openpowerbot | [slack] <Boris Shingarov> Oh, I see it now: in `syscon.vhdl` I see | 12:01 |
| openpowerbot | [slack] <Boris Shingarov> ```dram_at_0 <= '1' when BRAM_SIZE = 0 else reg_ctrl(SYS_REG_CTRL_DRAM_AT_0);``` | 12:01 |
| openpowerbot | [slack] <Boris Shingarov> Thanks!!! | 12:01 |
| openpowerbot | [slack] <joel> and in the gateware I use the bram is 0. Now I understand how it works, thanks for the reminder | 12:05 |
| openpowerbot | [slack] <Boris Shingarov> Does anyone actually use the `true` path through the `if (ftr & SYS_REG_INFO_HAS_BRAM) { ... }` in `microwatt/litedram/gen-src/sdram_init/main.c`? That case insists that BRAM contains literally the executable code at offset 0. I have a patch that introduces `boot_bram()`, which works similarly to `boot_flash()` in the sense that it expects an ELF, not raw executable. Then, I can just build with `f | 12:26 |
| openpowerbot | [mattermost] <lkcl> boris: we have a *lot* of changes that need merging in this area | 13:58 |
| openpowerbot | [mattermost] <lkcl> including a SIM_BRAM_CHAINBOOT parameter to be added to SYSCON | 13:58 |
| openpowerbot | [mattermost] <lkcl> https://git.libre-soc.org/?p=microwatt.git;a=shortlog;h=refs/heads/verilator_trace | 13:58 |
| openpowerbot | [mattermost] <lkcl> passing in a RESET_ADDRESS through the Makefile | 13:59 |
| openpowerbot | [mattermost] <lkcl> https://git.libre-soc.org/?p=microwatt.git;a=commitdiff;h=cac26c0b5e37c7c6843ba26634c4002be05417f8 | 13:59 |
| openpowerbot | [mattermost] <lkcl> https://git.libre-soc.org/?p=microwatt.git;a=commitdiff;h=6431824a5f37a3a3d729d407b43f1443de93ff98 | 13:59 |
| openpowerbot | [mattermost] <lkcl> and a "stand-alone BIOS" mode that disables sdram entirely but ensures that the BIOS compiles | 14:01 |
| openpowerbot | [mattermost] <lkcl> i use raw boot binaries in the verilator_trace branch for BRAM | 14:03 |
| openpowerbot | [mattermost] <lkcl> they are "uploaded" into verilator memory directly | 14:03 |
| openpowerbot | [mattermost] <lkcl> i was able to replicate joel's work booting linux-5.7 in verilator using these modifications | 14:05 |
| openpowerbot | [mattermost] <lkcl> https://git.libre-soc.org/?p=microwatt.git;a=blob;f=verilator/microwatt-verilator.cpp;h=a226393f6ba74d5e3e1ffdb729d731d2311d53ad;hb=ac4dd92b9d287d1267e7908da77eb41760b1853c | 14:05 |
| openpowerbot | [mattermost] <lkcl> yes, i assume that BRAM is raw code, it would make a lot more work for me if it was assumed to be ELF | 14:06 |
| openpowerbot | [slack] <Boris Shingarov> ::reading the diff:: | 14:07 |
| openpowerbot | [slack] <Boris Shingarov> but in the case of `cac26c0` control reaches the code in BRAM directly from reset, not through `microwatt/litedram/gen-src/sdram_init/main.c` -- or am I reading this wrong? | 14:07 |
| openpowerbot | [mattermost] <lkcl> i believe that's what the SIM_BRAM_CHAINBOOT parameter is for | 14:07 |
| openpowerbot | [mattermost] <lkcl> all of this was many months ago so i cannot directly recall exactly what i did | 14:08 |
| openpowerbot | [mattermost] <lkcl> the stand-alone BIOS performs the initialisation (of DDR3 etc) | 14:08 |
| openpowerbot | [mattermost] <lkcl> then CHAIN-boot jumps to the linux kernel which has been uploaded to BRAM already at address 0x6000_0000 | 14:09 |
| openpowerbot | [mattermost] <lkcl> sorry | 14:09 |
| openpowerbot | [mattermost] <lkcl> 0x60_0000 | 14:09 |
| openpowerbot | [mattermost] <lkcl> that gives plenty of space for the linux kernel to copy itself down to address 0x0000_0000 | 14:09 |
| openpowerbot | [mattermost] <lkcl> i've used this in both simulations and on FPGAs. | 14:13 |
| openpowerbot | [slack] <Boris Shingarov> > the stand-alone BIOS performs the initialisation | 14:13 |
| openpowerbot | [slack] <Boris Shingarov> By this you mean the `microwatt/litedram/gen-src/sdram_init/main.c` or something else? | 14:13 |
| openpowerbot | [slack] <Boris Shingarov> In any case, I think the solution is to simply parse the header at the beginning of BRAM, if it looks like valid ELF **and** it's the correct ELF class **and** the correct architecture then parse the ELF, otherwise assume raw bin. Am I missing some thing more? | 14:13 |
| openpowerbot | [mattermost] <lkcl> yes, main.c | 14:13 |
| openpowerbot | [mattermost] <lkcl> it *is* a stand-alone early-boot BIOS | 14:13 |
| openpowerbot | [mattermost] <lkcl> it *is* directly and functionally equivalent to u-boot-spl.bin | 14:14 |
| openpowerbot | [mattermost] <lkcl> has exactly the same purpose and exactly the same functionality. | 14:14 |
| openpowerbot | [slack] <Boris Shingarov> Yes, I understand. I was trying to confirm whether you meant the `main.c` in `microwatt/litedram/gen-src/sdram_init` or something else functionally equivalent. | 14:15 |
| openpowerbot | [mattermost] <lkcl> i made it work *without* requiring DRAM and added chain-loading | 14:16 |
| openpowerbot | [mattermost] <lkcl> sorry: added the ability to set the chain-loading address in SYSCON | 14:16 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!