[OpenBIOS] Re: CHRP booting.

[Jd Lyons]

Hmmm…….

One of the original people asking about ELF to COFF conversion (or
COFF to ELF) conversion, either here or in one of the other
newsgroups, was on an RS/6000. Note, that in the COFF space, there
are lots of COFF varients that have been extended in wild and wooly
ways from the original System V.3 COFF (to name 3 that have been used
in the past or are currently used, there is XCOFF on IBM/Mac/Be
systems, ECOFF on SGI, Mips, and DEC systems, and PE, which is used on
Windows NT systems).

In particular, for coversions between XCOFF and ELF on PowerPC
systems, it is nearly impossible. This is because XCOFF
(PowerOpen/AIX/Mac) and ELF (V.4/eabi/Linux) PowerPC systems use
different ABI's (and NT uses a slightly different ABI from AIX/Mac):

1) Only 8 floating point args are passed in registers in V.4 compared to
13 in PowerOpen and NT. Also under V.4, floating arguments passed in
floating registers don't cause the corresponding integer registers to
be skipped.

2) V.4 has no register save area for the 8 words passed in GP registers.

3) Varargs/stdarg support is completely different between the V.4 and
PowerOpen/NT. In particular, PowerOpen/NT passes floating args in both
integer and floating registers, and uses the register save area to make
one contiguous area. The va_list type is a char *. V.4 never passes
floating arguments in integer registers. The registers used to hold
arguments are saved in a separate save area, and va_list is an array of
1 element of a structure that contains pointers to the stack and
register save area, and two char variables indicating how many integer
and floating point registers have been processed. In addition, bit 6
of the condition code register is set to 1 if floating point arguments
were passed, and 0 if they were not.

4) V.4 doesn't support a TOC register. The eabi extension uses it as a
secondary small data area.

5) V.4 uses r13 to point to the small data area, while PowerOpen uses it
as a normal caller save register, and NT reserves it for use by the
operating system. PowerOpen

6) Where the LR/CR is stored on the stack is different in all three.

7) The static chain (environment pointer) is in r31 for V.4 and r11 for
PowerOpen. NT doesn't have a defined register for passing the static
chain, so GCC uses r11.

8) Under PowerOpen/NT, structures and unions are passed in registers or on
the stack like large integers, while V.4 copies them to a temporary
location and passes the pointer to that location.

9) A long long passed as word 7 is not split between the stack and the
register under V.4.

10) Alloca for V.4 must copy both the stack back chain and the return
address when extending the stack, while PowerOpen only copies the stack
back chain.

11) PowerOpen and NT use function descriptors, and function pointers point
to the function descriptor. The real function name is prefixed by one
or two periods. V.4 has function pointers point to the actual function
(which is not prefixed).

In other words, you have the same sort of compatibility issues as
going to a completely different machine and doing translation. It can
be done, but it will take a lot of sweat and engineering.
> On Sep 29, 2022, at 12:34 PM, Jd Lyons via OpenBIOS  wrote:
>
> Seems objcopy should be able to do this conversion from binutils, but perhaps I need to try objcopyppc as I’m not sure the input format is supported on arm64.
> > On Sep 29, 2022, at 10:37 AM, Jd Lyons via OpenBIOS <[e-mail] > wrote:
> >
> > Thanks Mark,
> >
> > I found a tool that says it can convert COFF to ELF format, but it says X86, so I’m not real sure it will work.
> >
> > https://www.agner.org/optimize/#objconv https://www.agner.org/optimize/#objconv
> >
> > I did manage to build it on macOS 12.6 on my AppleSoC PowerBook, but trying to convert with this command seems to error out:
> >
> > objconv -felf32 -nu /Users/jam/Downloads/objconv/BootX BootX.elf
> >
> > Error 2018: Unknown type 0x5248433C for file: /Users/jam/Downloads/objconv/BootX
> >
> > I would assume the COFF is COFF is COFF, but maybe this tool can’t convert for PPC COFF, if there is such a thing?
> > > On Sep 29, 2022, at 4:11 AM, Mark Cave-Ayland <[e-mail] > wrote:
> > >
> > > On 28/09/2022 18:30, Jd Lyons via OpenBIOS wrote:
> > > > I’m trying to figure how Openbios boots CHRP boot scrips like :tbxi, yet SOLF does not.
> > > > Can anyone point me to the code in Openbios that enables :tbxi/CHRP booting?
> > > > Also, does anyone know how exactly that works, what was done to Openbios to enable booting the Mac OS?
> > > > I’d really like to try and get Apple’s BootX to load on Qemu’s pseries machines and as I understand it CHRP booting should work in SLOF, but it just errors out on BootX with "bad executable”, so there must be some magic I need to understand about :tbxi CHRP boot scripts that SLOF needs some sort of patch.
> > >
> > > The boot scripts are really just an XML file that contains among other things, a Forth command to use when booting the media. You can find the simple parser in OpenBIOS at https://github.com/openbios/openbios/blob/master/libopenbios/bootinfo_load.c https://github.com/openbios/openbios/blob/master/libopenbios/bootinfo_load.c.
> > >
> > > I suspect what is happening in SLOF is that the XML is being parsed, however the resulting executable loaded isn't being recognised because it is in COFF rather than ELF format.
> > >
> > > ATB,
> > >
> > > Mark.
> > > _______________________________________________
> > > OpenBIOS mailing list -- [e-mail] 
> > > To unsubscribe send an email to [e-mail]
> >
> > OpenBIOS mailing list -- [e-mail] 
> > To unsubscribe send an email to [e-mail]
>
> OpenBIOS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]