CHRP booting.

[Jd Lyons]

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.

[Segher Boessenkool]

On Wed, Sep 28, 2022 at 01:30:19PM -0400, Jd Lyons via OpenBIOS wrote:
> I’m trying to figure how Openbios boots CHRP boot scrips like :tbxi, yet SOLF does not.

SLOF was not written for Apple systems.  Does it even support any
filesystem that has creator codes (and type codes)?
> 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.

Your bootx executable is not a supported executable file type either, I
bet.  For SLOF that is.

Segher

[Mark Cave-Ayland]

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.

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.

[BALATON Zoltan]

On Thu, 29 Sep 2022, Mark Cave-Ayland 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.
>
> 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.

Either that or SLOF can't read HFS file system to load it. There's an HFS 
driver in openfirmware in Forth 
(https://github.com/openbios/openfirmware/tree/master/ofw/fs/hfs) that 
could be tried to be ported but I don't see how can MacOS run on anything 
else than a Mac as it would need drivers to the different machine so there 
are probably much bigger problems ahead than just SLOF.

Regards,
BALATON Zoltan

[Jd Lyons]

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

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  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.
>
> 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]

[Jd Lyons]

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  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]

[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]

[Jd Lyons]

Ok,  looks like Openbios has an xcoff-loader package, I would need to port this to SLOF. That should get me to loading bootx.

The next stage would be loading the kernel and such from the files system, so I’d have to port the hfs/hfs+ packages to SLOF or bootx also supports ext2 file systems.

That would get me to the point of a kernel panic, likely, as there are no “platform drivers” for the IBM pSeries machines in OS X.
> On Sep 29, 2022, at 1:04 PM, Jd Lyons  wrote:
>
> 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):
> 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.
>
> V.4 has no register save area for the 8 words passed in GP registers.
>
> 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.
> V.4 doesn't support a TOC register. The eabi extension uses it as a
>
> secondary small data area.
> 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
>
> Where the LR/CR is stored on the stack is different in all three.
>
> 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.
> 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.
> A long long passed as word 7 is not split between the stack and the
>
> register under V.4.
> 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.
> 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 <[e-mail] > 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]