G5 boot test reports and how we should prepare tests

[IIO]

There might be also academic questions..when/where/why MacOS9 boot stops in G5.

CPU driver?

[Jubadub]

There might be also academic questions..when/where/why MacOS9 boot stops in G5.

CPU driver?

Let's find that 1.6GHz G5 and confirm it!

[chokobo]

Let's find that 1.6GHz G5 and confirm it!

I have one, but it's currently in pretty deep storage.

[teroyk]

Let's find that 1.6GHz G5 and confirm it!

I have one, but it's currently in pretty deep storage.

Can you dig it out someday? And take some pictures from inside? And check does it still boot to OSX and check how much memory it has?

[nanopico]

I'm trying to go off memory of a few things so bear with me here.
Many of you know I'm not the type to say something is impossible, but the G5 thing would be a tremendous undertaking.

I'll just bring up one point here with the boot code.  The trampoline (second stage boot loader here) loads OS 9 and is the bridge from OpenFirmware to OS 9. (Yes I understand this is not news). 
The equivalent in  OS X is bootx.   I've been disassembling and re-writing the trampoline code over the past few weeks. There are a lot of similarities of bootx and the trampoline code.  Almost to the point where Apple took the trampoline, stripped all code out of it related to parcels and added in code for loading the xnu kernel and called it good (well initially anyway).
So keep that in mind for a moment.
A 64bit PowerPC architecture can run 32bit processes and programs.  When it is run in 32bit mode it still has access to the 64bit address buss and it does some weird things with where it puts stuff regardless of the endianness.   So with the OpenFrimware client interface (used during early boot to transition from OpenFirmware to whatever OS you are starting) there is a specific service provided that takes a 64bit address as a paramter.  This paramter is 64bits regardless if the cpu is 32 or 64 bit.   
To make this service compitble the 64bit address is passed via two 32bit registers. 
Here's the signature from the first available version of bootx

Code: [Select]

CICell Seek(CICell ihandle, long long position)so you have position as a 64bit address;
The method then takes the top half of the address and put it in register GPR7 and the lower half in GPR8 (this is the location where it's expected in call to the open firmware client interface)
So OS X could be booted on a 64bit machine from the get go even if it was only running 32bit code.
No move over to the same function in the trampoline.  It only excepts a 32bit address and always sets the top 32bits to zero.  So GPR7 is always 0
Here's the disassembled code that does this from the trampoline. (sorry I know I'm mixing the c signature above and assembly below)

Code: [Select]

cmpwi          r3, 0                   
beqlr                                   
mflr          r0                       
stw            r0, 8(r1)               
stwu          r1, -0x40(r1)           
addi          r9, r1, 0x38             
mr            r6, r3                   
lwz            r3, -0x1e8(r2)           
mr            r8, r4                   
addi          r3, r3, 0x84
li            r4, 3
li            r5, 1
li            r7, 0 ; r7 is set to zero always this is the upper address
bl            0x20dbec                  ;call openfirmware service "seek"
nop                   
addi          r1, r1, 0x40
lwz            r0, 8(r1)
mtlr          r0
blr

Generally probably not a big deal, but not sure where all the seek method is used and how yet, I would say that there is a reason they fixed this with bootx.
 Sorry maybe I'm rambling, but until we can confidently get the trampoline to complete, then any other thoughts I think are moot at this point.
But again back to the disassembly of the trampoline.  Once i have it ported to c and can compile a bootable system with it then I think we can start thinking about more things and looking at what it might take.

There is also a method loads a lot of cpu properties into a structure to likely hand of to the nanokernel and if a single one is missing it bails immediately.

So okay relevant or not I still think there is a sliver of hope (although just a small sliver)

And I do have a 1.6ghz G5 so I may be able to try some stuff again around the upcoming holidays.  Got some time off work.

[Jubadub]

Sorry maybe I'm rambling [...]

Far from it, I loved the insight! It's the sort of post that helps us take an otherwise-unrealistic dream (booting OS 9 on G5 and other 64-bit PPC) towards realized potential in a realistic way (how to get there, what to watch out for, where to start, and what is the current situation now).

The detailed description of the trampoline and how it compares to bootX were both clear and educational.

This may sound like the weirdest question ever, but could we somehow "merge" bootX with the trampoline by hacking bootX in such a way so that once it is done with its job of loading a number of things required for booting, and done preparing a bunch of the data for it, it "passes the batton over" to the trampoline instead of what would normally happen? Or something along those lines? Something like a Frankenstein job between bootX and the trampoline.

It may not be the same as what I posed in my question above, but what I have seen with OS 9 is that if you have a partition OS 9 normally cannot boot with, and you select another partition OS 9 also cannot boot with, you nonetheless can try to boot with one of them, which will then obviously fail, but then the machine tries to seek elsewhere for a valid boot partition, and once it tries to load from the other partition that, by itself, would not boot, it WILL then boot successfully. I saw this happen with the 1.5GHz Mac mini G4 back in 2018, and personally exploited this behavior to get an otherwise-unbootable drive to boot. As if the first attempt loaded some of the data into RAM which, then, was enough for the second attempt to carry things forward with.

By the way, just in case anyone else wants to "join up" and get up to speed with your efforts towards your trampoline pursuits, what tools are you using for inspecting things and writing/assembling/compiling code? MacNosy/MacsBug, ResEdit/Resorcerer, Mac emulators like QEMU/SheepShaver? Retro68/MPW/CodeWarrior/Fantasm/Visual Studio Code/VSCodium with PPC (POWER) assembly plug-in (for intelliSense and syntax highlighting)? ELN's many fantastic Mac OS reverse engineering tools with Python 3? Ghidra/Cutter/IDA/radare2/Snowman and/or other disassemblers/decompilers?

[nanopico]

This may sound like the weirdest question ever, but could we somehow "merge" bootX with the trampoline by hacking bootX in such a way so that once it is done with its job of loading a number of things required for booting, and done preparing a bunch of the data for it, it "passes the batton over" to the trampoline instead of what would normally happen? Or something along those lines? Something like a Frankenstein job between bootX and the trampoline.

Well I originally thought this may be a workable solution actually as I started down this, but as I got farther in I realized there similarities, but I think enough differences that it might overly complicate things and cause more problems than it solves.

By the way, just in case anyone else wants to "join up" and get up to speed with your efforts towards your trampoline pursuits, what tools are you using for inspecting things and writing/assembling/compiling code? MacNosy/MacsBug, ResEdit/Resorcerer, Mac emulators like QEMU/SheepShaver? Retro68/MPW/CodeWarrior/Fantasm/Visual Studio Code/VSCodium with PPC (POWER) assembly plug-in (for intelliSense and syntax highlighting)? ELN's many fantastic Mac OS reverse engineering tools with Python 3? Ghidra/Cutter/IDA/radare2/Snowman and/or other disassemblers/decompilers?

I'm kind of a gluten for punishment so you may find this one out there.  I wrote a disassembler using capstone. 
Then I went through all the code by hand commenting it, and cross referencing references to the data section and I'm manually re-writting every assembly method in c.  Partly because it is the way my brain functions and partly because it forces me to understand every single thing in there.  So the tools are a custom disassembler, a text editor (depending on where I'm working on it it is anything from notepad++, vscode or mpw) a hex editor (again dependent on where I'm working no single one specificly) and then right now the only compiler I've figure out how to easily build it on is gcc.  I'd like to figure out how to compile it in with mrc in mpw eventually but eh.
I like to use hardware for testing so I'll end up testing on hardware when I get far enough. I might try qemu too, but I figure it has to run on hardware eventually, start there.

[ssp3]

I wrote a disassembler using capstone.

Not bad 

 
Then I went through all the code by hand commenting it, and cross referencing references to the data section and I'm manually re-writting every assembly method in c.

Have you tried Hopper? It now supports PPC and it has some sort of pseudo-c decompiler.

[nanopico]

Have you tried Hopper? It now supports PPC and it has some sort of pseudo-c decompiler.

No.  Like I said part of this is the way my brain works and using tools like like this makes it more difficult for me to understand the code.  By going through it this way I end up knowing it really well and understanding it.  But that is just me. 

My problem with most decompilers is that if there are no debug symbols then any hints as to method names or variable names is lost so all though you get valid c (or whatever language) you still end up spending a lot of time figuring it out.  So I like to manually walk through it so I understand it and while writing the c I can give things meaningful names so that the c is hopefully easier to read and understand. Just a preference.  I know several people who can use those tools with great success and that's awesome.

[teroyk]

What version of "ROM"-file G5 1.6Ghz Recovery disk install to boot drive?