On Wed, 1 May 2019, Atish Patra wrote:That would be inventing our RISC-V specific header format. However, we can always use the one of the reserved fields in proposed header (res4) for this purpose.
Currently, last stage boot loaders such as U-Boot can accept only
uImage which is an unnecessary additional step in automating boot flows.
Add a PE/COFF compliant image header that boot loaders can parse and
directly load kernel flat Image. The existing booting methods will continue
to work as it is.
Another goal of this header is to support EFI stub for RISC-V in future.
EFI specification needs PE/COFF image header in the beginning of the kernel
image in order to load it as an EFI application. In order to support
EFI stub, code0 should be replaced with "MZ" magic string and res5(at
offset 0x3c) should point to the rest of the PE/COFF header (which will
be added during EFI support).
Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux.
Signed-off-by: Atish Patra <atish.patra@xxxxxxx>
Seems like we're stuck with this basic format for EFI, etc. Even though
we may be stuck with it, I think we should take the opportunity to add the
possibility to extending this header format by adding fields after the
basic PE/COFF header ends.
In particular, at the very least, I'd suggest adding a u32 after the
PE/COFF header ends, to represent a "RISC-V header format version number".
Then if we add more fields that follow the PE/COFF header -- for example,
to represent the RISC-V instruction set extensions that are required to
run this binary -- we can just bump that RISC-V-specific version number
field to indicate to bootloaders that there's more there.
One other observation - if what's here was copied from some other
architecture, like ARM, please acknowledge the source in the patch
description.
thanks
- Paul