[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbios
Subject:    [OpenBIOS] Re: CHRP booting.
From:       Jd Lyons via OpenBIOS <openbios () openbios ! org>
Date:       2022-10-03 10:06:27
Message-ID: 5294B590-C981-43CE-8307-A8DD02F792AF () yahoo ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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 <lyons_dj@yahoo.com> 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):
> 
> 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 <openbios@openbios.org \
> > <mailto:openbios@openbios.org>> 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 <openbios@openbios.org \
> > > <mailto:openbios@openbios.org>> 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 <mark.cave-ayland@ilande.co.uk \
> > > > <mailto:mark.cave-ayland@ilande.co.uk>> 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 -- openbios@openbios.org <mailto:openbios@openbios.org>
> > > > To unsubscribe send an email to openbios-leave@openbios.org \
> > > > <mailto:openbios-leave@openbios.org>
> > > 
> > > _______________________________________________
> > > OpenBIOS mailing list -- openbios@openbios.org <mailto:openbios@openbios.org>
> > > To unsubscribe send an email to openbios-leave@openbios.org \
> > > <mailto:openbios-leave@openbios.org>
> > 
> > _______________________________________________
> > OpenBIOS mailing list -- openbios@openbios.org <mailto:openbios@openbios.org>
> > To unsubscribe send an email to openbios-leave@openbios.org \
> > <mailto:openbios-leave@openbios.org>
> 


[Attachment #5 (unknown)]

<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class="">Ok,&nbsp;<span style="caret-color: rgb(0, 0, \
0); color: rgb(0, 0, 0);" class="">&nbsp;</span><span style="caret-color: rgb(0, 0, \
0); color: rgb(0, 0, 0);" class="">looks like Openbios has an xcoff-loader package, I \
would need to port this to SLOF. That should get me to loading bootx.</span><div \
style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br \
class=""></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" \
class="">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.</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" \
class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, \
0);" class="">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.</div><div><br \
class=""><blockquote type="cite" class=""><div class="">On Sep 29, 2022, at 1:04 PM, \
Jd Lyons &lt;<a href="mailto:lyons_dj@yahoo.com" class="">lyons_dj@yahoo.com</a>&gt; \
wrote:</div><br class="Apple-interchange-newline"><div class=""><meta \
http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div \
style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: \
after-white-space;" class="">Hmmm…….<div class=""><br class=""></div><div \
class=""><p style="caret-color: rgba(0, 0, 0, 0.87); font-family: Roboto, \
RobotoDraft, Helvetica, Arial, sans-serif; font-size: 14px;" class="">One of the \
original people asking about ELF to COFF conversion (or<br class="">COFF to ELF) \
conversion, either here or in one of the other<br class="">newsgroups, was on an \
RS/6000. Note, that in the COFF space, there<br class="">are lots of COFF varients \
that have been extended in wild and wooly<br class="">ways from the original System \
V.3 COFF (to name 3 that have been used<br class="">in the past or are currently \
used, there is XCOFF on IBM/Mac/Be<br class="">systems, ECOFF on SGI, Mips, and DEC \
systems, and PE, which is used on<br class="">Windows NT systems).</p><p \
style="caret-color: rgba(0, 0, 0, 0.87); font-family: Roboto, RobotoDraft, Helvetica, \
Arial, sans-serif; font-size: 14px;" class="">In particular, for coversions between \
XCOFF and ELF on PowerPC<br class="">systems, it is nearly impossible. This is \
because XCOFF<br class="">(PowerOpen/AIX/Mac) and ELF (V.4/eabi/Linux) PowerPC \
systems use<br class="">different ABI's (and NT uses a slightly different ABI from \
AIX/Mac):</p><p style="caret-color: rgba(0, 0, 0, 0.87); font-family: Roboto, \
RobotoDraft, Helvetica, Arial, sans-serif; font-size: 14px;" class="">1) Only 8 \
floating point args are passed in registers in V.4 compared to<br class="">13 in \
PowerOpen and NT. Also under V.4, floating arguments passed in<br class="">floating \
registers don't cause the corresponding integer registers to<br class="">be \
skipped.</p><p style="caret-color: rgba(0, 0, 0, 0.87); font-family: Roboto, \
RobotoDraft, Helvetica, Arial, sans-serif; font-size: 14px;" class="">2) V.4 has no \
register save area for the 8 words passed in GP registers.</p><p style="caret-color: \
rgba(0, 0, 0, 0.87); font-family: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; \
font-size: 14px;" class="">3) Varargs/stdarg support is completely different between \
the V.4 and<br class="">PowerOpen/NT. In particular, PowerOpen/NT passes floating \
args in both<br class="">integer and floating registers, and uses the register save \
area to make<br class="">one contiguous area. The va_list type is a char *. V.4 never \
passes<br class="">floating arguments in integer registers. The registers used to \
hold<br class="">arguments are saved in a separate save area, and va_list is an array \
of<br class="">1 element of a structure that contains pointers to the stack and<br \
class="">register save area, and two char variables indicating how many integer<br \
class="">and floating point registers have been processed. In addition, bit 6<br \
class="">of the condition code register is set to 1 if floating point arguments<br \
class="">were passed, and 0 if they were not.</p><p style="caret-color: rgba(0, 0, 0, \
0.87); font-family: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; font-size: \
14px;" class="">4) V.4 doesn't support a TOC register. The eabi extension uses it as \
a<br class="">secondary small data area.</p><p style="caret-color: rgba(0, 0, 0, \
0.87); font-family: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; font-size: \
14px;" class="">5) V.4 uses r13 to point to the small data area, while PowerOpen uses \
it<br class="">as a normal caller save register, and NT reserves it for use by the<br \
class="">operating system. PowerOpen</p><p style="caret-color: rgba(0, 0, 0, 0.87); \
font-family: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; font-size: 14px;" \
class="">6) Where the LR/CR is stored on the stack is different in all three.</p><p \
style="caret-color: rgba(0, 0, 0, 0.87); font-family: Roboto, RobotoDraft, Helvetica, \
Arial, sans-serif; font-size: 14px;" class="">7) The static chain (environment \
pointer) is in r31 for V.4 and r11 for<br class="">PowerOpen. NT doesn't have a \
defined register for passing the static<br class="">chain, so GCC uses r11.</p><p \
style="caret-color: rgba(0, 0, 0, 0.87); font-family: Roboto, RobotoDraft, Helvetica, \
Arial, sans-serif; font-size: 14px;" class="">8) Under PowerOpen/NT, structures and \
unions are passed in registers or on<br class="">the stack like large integers, while \
V.4 copies them to a temporary<br class="">location and passes the pointer to that \
location.</p><p style="caret-color: rgba(0, 0, 0, 0.87); font-family: Roboto, \
RobotoDraft, Helvetica, Arial, sans-serif; font-size: 14px;" class="">9) A long long \
passed as word 7 is not split between the stack and the<br class="">register under \
V.4.</p><p style="caret-color: rgba(0, 0, 0, 0.87); font-family: Roboto, RobotoDraft, \
Helvetica, Arial, sans-serif; font-size: 14px;" class="">10) Alloca for V.4 must copy \
both the stack back chain and the return<br class="">address when extending the \
stack, while PowerOpen only copies the stack<br class="">back chain.</p><p \
style="caret-color: rgba(0, 0, 0, 0.87); font-family: Roboto, RobotoDraft, Helvetica, \
Arial, sans-serif; font-size: 14px;" class="">11) PowerOpen and NT use function \
descriptors, and function pointers point<br class="">to the function descriptor. The \
real function name is prefixed by one<br class="">or two periods. V.4 has function \
pointers point to the actual function<br class="">(which is not prefixed).</p><p \
style="caret-color: rgba(0, 0, 0, 0.87); font-family: Roboto, RobotoDraft, Helvetica, \
Arial, sans-serif; font-size: 14px;" class="">In other words, you have the same sort \
of compatibility issues as<br class="">going to a completely different machine and \
doing translation. It can<br class="">be done, but it will take a lot of sweat and \
engineering.</p><div class=""><br class=""><blockquote type="cite" class=""><div \
class="">On Sep 29, 2022, at 12:34 PM, Jd Lyons via OpenBIOS &lt;<a \
href="mailto:openbios@openbios.org" class="">openbios@openbios.org</a>&gt; \
wrote:</div><br class="Apple-interchange-newline"><div class=""><meta \
http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div \
style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: \
after-white-space;" class="">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.<div class=""><br class=""></div><div class=""><br class=""><div \
class=""><br class=""><blockquote type="cite" class=""><div class="">On Sep 29, 2022, \
at 10:37 AM, Jd Lyons via OpenBIOS &lt;<a href="mailto:openbios@openbios.org" \
class="">openbios@openbios.org</a>&gt; wrote:</div><br \
class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" \
content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; \
-webkit-nbsp-mode: space; line-break: after-white-space;" class="">Thanks \
Mark,&nbsp;<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><a \
href="https://www.agner.org/optimize/#objconv" \
class="">https://www.agner.org/optimize/#objconv</a></div><div class=""><br \
class=""></div><div class="">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:</div><div \
class=""><br class=""></div><div class=""><div style="margin: 0px; font-stretch: \
normal; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span \
style="font-variant-ligatures: no-common-ligatures" class="">objconv -felf32 -nu \
/Users/jam/Downloads/objconv/BootX BootX.elf&nbsp;</span></div><div style="margin: \
0px; font-stretch: normal; font-size: 11px; line-height: normal; font-family: Menlo; \
min-height: 13px;" class=""><span style="font-variant-ligatures: no-common-ligatures" \
class=""></span><br class=""></div><div style="margin: 0px; font-stretch: normal; \
font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span \
style="font-variant-ligatures: no-common-ligatures" class="">Error 2018: Unknown type \
0x5248433C for file: /Users/jam/Downloads/objconv/BootX</span></div><div \
style="margin: 0px; font-stretch: normal; font-size: 11px; line-height: normal; \
font-family: Menlo;" class=""><span style="font-variant-ligatures: \
no-common-ligatures" class=""><br class=""></span></div><div style="margin: 0px; \
font-stretch: normal; font-size: 11px; line-height: normal; font-family: Menlo;" \
class=""><span style="font-variant-ligatures: no-common-ligatures" class="">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?</span></div><div class=""><br class=""><blockquote type="cite" \
class=""><div class="">On Sep 29, 2022, at 4:11 AM, Mark Cave-Ayland &lt;<a \
href="mailto:mark.cave-ayland@ilande.co.uk" \
class="">mark.cave-ayland@ilande.co.uk</a>&gt; wrote:</div><br \
class="Apple-interchange-newline"><div class=""><div class="">On 28/09/2022 18:30, Jd \
Lyons via OpenBIOS wrote:<br class=""><br class=""><blockquote type="cite" \
class="">I'm trying to figure how Openbios boots CHRP boot scrips like :tbxi, yet \
SOLF does not.<br class="">Can anyone point me to the code in Openbios that enables \
:tbxi/CHRP booting?<br class="">Also, does anyone know how exactly that works, what \
was done to Openbios to enable booting the Mac OS?<br class="">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.<br class=""></blockquote><br class="">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 <a \
href="https://github.com/openbios/openbios/blob/master/libopenbios/bootinfo_load.c" \
class="">https://github.com/openbios/openbios/blob/master/libopenbios/bootinfo_load.c</a>.<br \
class=""><br class="">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.<br class=""><br class=""><br class="">ATB,<br \
class=""><br class="">Mark.<br \
class="">_______________________________________________<br class="">OpenBIOS mailing \
list -- <a href="mailto:openbios@openbios.org" class="">openbios@openbios.org</a><br \
class="">To unsubscribe send an email to <a href="mailto:openbios-leave@openbios.org" \
class="">openbios-leave@openbios.org</a><br \
class=""></div></div></blockquote></div><br \
class=""></div></div>_______________________________________________<br \
class="">OpenBIOS mailing list -- <a href="mailto:openbios@openbios.org" \
class="">openbios@openbios.org</a><br class="">To unsubscribe send an email to <a \
href="mailto:openbios-leave@openbios.org" class="">openbios-leave@openbios.org</a><br \
class=""></div></blockquote></div><br \
class=""></div></div>_______________________________________________<br \
class="">OpenBIOS mailing list -- <a href="mailto:openbios@openbios.org" \
class="">openbios@openbios.org</a><br class="">To unsubscribe send an email to <a \
href="mailto:openbios-leave@openbios.org" class="">openbios-leave@openbios.org</a><br \
class=""></div></blockquote></div><br \
class=""></div></div></div></blockquote></div><br class=""></body></html>



_______________________________________________
OpenBIOS mailing list -- openbios@openbios.org
To unsubscribe send an email to openbios-leave@openbios.org


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic