[SLOF] [PATCH] OF: Add a separate direct kernel loading word
segher at kernel.crashing.org
Thu Jul 14 04:11:34 AEST 2022
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?
> 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
, and extended by section 10.4.1.1., or PE (Portable Executable)
as defined by . 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 :-)
More information about the SLOF