lkml.org 
[lkml]   [2019]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [v2 PATCH] RISC-V: Add a PE/COFF compliant Image header.
On Mon, 13 May 2019, Atish Patra wrote:

> On 5/13/19 3:31 PM, Paul Walmsley wrote:
> > On Wed, 1 May 2019, Atish Patra wrote:
> >
> > > 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@wdc.com>
> >
> > 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.
> >
> 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.

What are the semantics of those reserved fields?

> Do we need to add it now or add it later when we actually need a version
> number. My preference is to add it later based on requirement.

If it isn't added now, how would bootloaders know whether it was there or
not?


- Paul

\
 
 \ /
  Last update: 2019-05-14 02:09    [W:0.077 / U:31.028 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site