-
Notifications
You must be signed in to change notification settings - Fork 11
Description
Currently, QEMU support for Earlgrey flash images hard-codes some assumptions and simplifies in some cases. In particular:
- There is currently no support for CRC/ECC storage in the flash backend to support ECCs/ICVs for flash scrambling.
flashgen.py
only supports loading "exec" files or "exec" and "boot" files, analogous to running code after the ROM, or running a ROM_EXT (after the ROM), and then booting into code. It hard-codes offsets for these files, and generally does not support placing boot files in different locations, or having multiple binaries (e.g. different boot stages) in different locations.- As part of this, currently
flashgen.py
seems to support signing images and building boot headers - it isn't clear if this is still relevant or if it is sufficient to just take signed OpenTitan binaries as inputs.
- As part of this, currently
flashgen.py
hard-codes flash images for only four ELFs - one for exec and one for boot in both banks 0 and 1. This is not generic across the number of banks, does not support ELFs for multiple binaries, and does not support the use case where you may have multiple ELFs to attach to one binary. Ideally, the image should have a mechanism for attaching an arbitrary number of ELFs containing debug symbols (which can still be checked for address range byflashgen.py
) which are then discovered and loaded by QEMU.- Now that flash is mutable in QEMU, there is also no support for invalidating ELF symbols (or at least warning if not trivially possible in QEMU) when overwriting the blobs corresponding to ELFs in flash.
- The flash controller itself (
hw/opentitan/ot_flash.c
) appears to only load the ELFs for the two bank 0 files, and ignores the two subsequent bank 1 ELFs.
An appropriate solution would be to: bump the flash format version header, and add information to the header about ECCs/checksums. Also update the debug trailer to allow a variable number of ELFs, and store metadata about each ELF (offset and size, maybe validity) to support invalidating/clearing ELFs when the associated blobs are overwritten. The flash controller should then be updated to support this new format and load any uncleared/non-invalidated ELFs at startup. It should also remove debug symbols (/warn if not possible) when writing to one of these offsets. flashgen.py
should be updated to support this, removing the "exec" and "boot" files and instead just supporting arbitrary blobs at arbitrary offsets (these 2 file types can be added back on top if needed).