[SLOF] [PATCH] OF: Add a separate direct kernel loading word

[Segher Boessenkool]

Hi!

On Wed, Jul 13, 2022 at 02:13:06PM +1000, Alexey Kardashevskiy wrote:
> On 7/12/22 23:48, Segher Boessenkool wrote:
> >Ouch.  So you run 64-bit programs in 32-bit mode as well, just hoping
> >they will deal with it?  Not a good idea :-(  Current Linux is fine with
> >it, but are other payloads, including future Linux?
> 
> https://www.devicetree.org/open-firmware/bindings/ppc/release/ppc-2_1.html 
> says "Upon entry to the client program, the following registers shall 
> contain the following values: ... msr ... SF=0, 32-bit mode". I'd think 
> that it is up to that client program to adjust MSR_SF, not the firmware.

The (later) PowerPC CHRP binding says (in 10.4):
  The data format of a client program compliant with this specification
  shall be either ELF (Executable and Linkage Format) as defined by
  [19], and extended by section 10.4.1.1., or PE (Portable Executable)
  as defined by [17]. The standard ELF format contains explicit
  indication as to the program's execution modes (e.g., 32- or 64-bit,
  Big- or Little-Endian). CHRP only supports the 32-bit version (i.e.,
  ELFCLASS32) for 32 and 64 bit platforms.  Note: other client program
  formats may be supported, in an implementation specific manner, by an
  Open Firmware implementation.

Supporting 64-bit ELF is thus explicitly allowed as well, and various
implementations do just that.

> >"init-program" is supposed to set the MSR state correctly (in ciregs
> >>srr1), based on the ELF headers (and btw the same is true for the LE
> >flag etc).  A little ELF parsing is needed.
> 
> This is the case when QEMU runs with "-kernel zImage" - QEMU loads the 
> ELF and SLOF has no idea what was the binary. QEMU does store a 
> "/chosen/qemu,boot-kernel-le" property but there is nothing for 32bit.

Ah, that sucks.  Then you'll just have to do what you have to do, no
matter how awful it is :-(

> >Hope this helps,
> 
> Always does! :)

Great to hear that :-)


Segher