[OpenBIOS] Re: CHRP booting.

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