[sw-sysemu] erbium boot protocol support - #119
Conversation
c2690dd to
afeba21
Compare
glguida
left a comment
glguida
left a comment
There was a problem hiding this comment.
Possibly a better way to implement this would be to add:
--payload_pc/sp or --boot_pc/sp (payload is a bootrom term afterall) to manually set them
or
--payload_elf (or boot_elf) to indicate that an elf is special.
And I would -- in the examples -- define the system area (once we settle on a size) on a different area altogether (MSYS), rather than defining MRAM and them manually decreasing the size and increasing the start.
cf78857 to
39f9e88
Compare
|
@glguida I think I addressed all the comments, if I got them right. |
|
Almost. :-) The major prolbem I have with this is that this also changes the option for ETSOC-1 sysemu. That's not good and need to be changed. Then I would go to either using boot or payload, not a mix of both. |
d40d352 to
c091932
Compare
|
@glguida The new boot_elf is now safeguarded with I also thought about putting a EMU_HAS_BOOTROM flag, but it would be confusing as ET-SoC1 also has a ROM, the design in the simulator is just different. Let me know if this is it. |
|
Okay thats' better now. Please let's maintain some commit hygiene, do not add fixes on top of a PR, just fix the original comments. One thing that would be really useful would be a checker that we're not writing the system area. would be nice if that was an option. |
Is "system area" the first 0x100 of the MRAM? We are checking that PMA and on boot_load. |
c091932 to
d7a2ed1
Compare
Sorry I completely missed that part. But this is not how hardware behaves, right? |
Warn when software stores to the first 256 bytes of MRAM (0x40000000- 0x400000FF), which is reserved for boot protocol vectors. The store is allowed through (no fault) since the hardware does not enforce write protection here — the bootrom sets up MPROT for that. Uses WARN_HART(memory, ...) so -Werror=memory promotes it to an error. Cache operations are exempt since they don't modify data.
Start MRAM at MRAM_BASE + 256 in linker scripts so code and data are placed after the boot protocol reserved region. Update tests that used hardcoded addresses within the reserved range.
Change return type from void to uint64_t so callers can capture the entry address from the ELF header. No existing callers are modified.
Platform-dispatched method that reads payload PC and SP from MRAM boot vectors and sets enabled harts accordingly. CLI overrides (payload_pc, payload_sp) are written to MRAM before reading, so the MRAM always reflects the actual boot configuration. Erbium implementation reads from MRAM offsets 0x28 (PC) and 0x20 (SP). Declaration and implementation are guarded with EMU_ERBIUM. Follows the same dispatcher pattern as pma.cpp (boot-protocol.cpp includes boot-protocol_er.cpp based on platform).
d7a2ed1 to
cf03713
Compare
As agreed privately, I added a way of addressing this error that is not emulating HW, as that region can indeed be written in HW, but shouldn't. I chose just a WARN_HART instead of a full checker class given the relatively small scope of this problem and to avoid boilerplate code that would come with a full checker for something that we can do inline. Please, let me know if you agree. I also have a question - should we only use this when we are using the flags for emulating bootROM in the simulator? |
… protocol Add boot_elf, payload_pc and payload_sp CLI flags for Erbium boot protocol control. --boot_elf loads an ELF and uses its entry point as the payload PC. --payload_pc/--payload_sp override explicitly. After warm reset, call apply_boot_protocol() which writes any CLI overrides to MRAM, reads the final boot vectors, and sets all enabled harts' PC and SP accordingly. Only runs when at least one boot protocol flag is specified. All flags and logic are guarded with EMU_ERBIUM. Help text included.
Add tests for the Erbium boot protocol: - boot_protocol_pc: verify --boot_elf sets PC from ELF entry point - boot_protocol_sp: verify --payload_sp sets initial stack pointer - pma_mram_boot_region: verify stores to boot protocol region succeed (with warning, no fault) Add run-boot-protocol Makefile target that re-runs all tests with --boot_elf to verify they work under the boot protocol flow.
cf03713 to
c61500f
Compare
3 participants
This allows users to rely on the erbium boot protocol without needing the actual bootrom code. For app developers using a simulator without timing modelling, the only real implication is how PC and SP get set at the beginning, either automatically from the ELF entry point or explicitly via --payload_pc/--payload_sp.
Creating a new method and three flags was the cleanest approach to this I could find.
From now on, the first 128 bytes of the MRAM are reserved to boot protocol.