G5 qemu attempts.

[ELN]

Are we reasonably confident that the G5 is in 32-bit mode when the Trampoline gets control? I’m trying to imagine what would happen if you ran code intended for 32-bit PPC under 64-bit mode, and I can imagine it working.

Also, Max, have you yet reversed the stuff that interprets “Reg” properties?

[Naiw]

KVM does not emulate the CPU at all at OSE/VSE level.

It can fake the PVR bits but that doesn't affect the emulation. (At UISA level the KVM-PR module can do some instruction emulation, but it doesn't attempt anything else as far as I know) KVM on the x86 works the same.

[Naiw]

To clarify if you say -cpu 604 to qemu when using kvm that does not mean you will run as a 604, if you have a G5 a G5 is what the guest OS will get. It will however lie cause it traps the PVR bits and will return 604.

Kvm is fast because it does NOT emulate but rather passthrough the hardware as is, the very same reason QEmu without kvm is quite slow as it has to emulate things like address translation that occurs virtually all the time.

There is no way around that, an MMU on an arbitrary CPU can't be reconfigured to behave like an MMU on a totally different processor so either you passthrough and accept that or you emulate and have absolutely no benefit from KVM.

The PPC kvm is a bit different though as they have kvm-hv (pure hypervisor/passthrough as all other kvm Arch's) and kvm-pr (problem mode) kvm-pr runs code in problem mode and traps instructions it can't understand this is sort of a middle ground (this is very much what MacOnLinux used to do) however as I said it does not and can not emulate the memory management.

And back to the (non) issue about OS X on the G5,
OS X gives rat about the platform a particular CPU is on, it have absolutely no problem running a G5 with a mac99 motherboard. It's handled by different parts of the system, the platform expert just loads the drivers based on what the device tree says- if there is any CPU expectation within any of these drivers they're faulty/incorrectly written.

[powermax]

Also, Max, have you yet reversed the stuff that interprets “Reg” properties?

Yes. As for memory regions, the stuff is located in utils.c:CalcRAMSize().

Device tree walking code also interprets "reg" properties attached to various devices in order to calculate device's base address. That stuff is much more complex. It has been reversed as well but still need a cleanup.

[powermax]

And back to the (non) issue about OS X on the G5,

Let's get back on track. OS 9 Trampoline doesn't depend on a particular CPU until we'll get into RelocationEngine that reprograms BATs. But that's the last step before the Nanokernel, just after OF has been shut down.
For the moment being, we didn't get so far due to the fatal error caused by overlapping relocation regions.

The Trampoline code depends on OF and MMU. Regarding the former, OpenBIOS is not the same as Apple's proprietary OF implementation - it can behave differently and thus cause the Trampoline to fail.

It can also be an issue with 64-bit MMU. That's what we need to figure out by means of debugging.

In the case of the G5, I expect we could "fix" OS 9 booting, given enough time and testing, but we may end up changing some of the G5 CPU emulation in ways that breaks linux booting.

You're right regarding our ability to fix OS 9 boot on G5. But we aren't going to break the existing QEMU emulation, we'll fix the Trampoline instead. That's why I'm working hard on finishing its decompilation.

[Naiw]

And back to the (non) issue about OS X on the G5,

Let's get back on track. OS 9 Trampoline doesn't depend on a particular CPU until we'll get into RelocationEngine that reprograms BATs. But that's the last step before the Nanokernel, just after OF has been shut down.
For the moment being, we didn't get so far due to the fatal error caused by overlapping relocation regions.

The Trampoline code depends on OF and MMU. Regarding the former, OpenBIOS is not the same as Apple's proprietary OF implementation - it can behave differently and thus cause the Trampoline to fail.

It can also be an issue with 64-bit MMU. That's what we need to figure out by means of debugging.

Absolutely, but this been discussed before and the attempt is quite futile since the 970 don't have any BATs.

The fact that the 970 can run OS 9 (ie. UISA compatibility, excluding eventual driver issues etc) is already demonstrated by the Blue box/Classic.

And yes you are right that openbios is different, but it should also be noted that the compatibility problem has been fixed enough to at least boot OS 9 with a 32 bit PPC. If the 64 bit and 32 bit use the same openbios images I don't recall however.

[ELN]

I believe that the 970 actually does have BATs. They are absent from the 970FX and 970MP.

But we could patch the kernel, or soon the Trampoline, not to use them.

[darthnVader]

I setup gdb-multiarch, I think it will work for what we need here, but I'm unsure what breakpoint to set?

[powermax]

I setup gdb-multiarch, I think it will work for what we need here, but I'm unsure what breakpoint to set?

I need to know your Trampoline version first. Can you tell me its MD5 checksum? Or upload your "Mac OS ROM" somewhere for me to grab?

[darthnVader]

Mac OS ROM 9.2.1, unmodified.

[powermax]

Mac OS ROM 9.2.1, unmodified.

I don't have this image, sorry. Fortunately, there is no big difference between Trampolines in OS 9.2.x.

IIRC, Trampoline is loaded by the Forth boot script and mapped into memory starting at 0x100000 (data sections) and 0x200000 (executable code). I hope that's correct.

You want to set a breakpoint at the subroutine @ 0x2025F4 (CalcRAMSize) and ensure that it works as expected: the first double word of SystemInfo (PPC register @r3 will point to it at exit of this function) should contain the correct size of the assigned memory (1024 MB).

I'm pretty sure that CalcRAMSize works as expected. It's meant to be a test ensuring that you can break into the Trampoline and trace its code.

[darthnVader]

Mac OS ROM 9.2.1, unmodified.

I don't have this image, sorry. Fortunately, there is no big difference between Trampolines in OS 9.2.x.

IIRC, Trampoline is loaded by the Forth boot script and mapped into memory starting at 0x100000 (data sections) and 0x200000 (executable code). I hope that's correct.

You want to set a breakpoint at the subroutine @ 0x2025F4 (CalcRAMSize) and ensure that it works as expected: the first double word of SystemInfo (PPC register @r3 will point to it at exit of this function) should contain the correct size of the assigned memory (1024 MB).

I'm pretty sure that CalcRAMSize works as expected. It's meant to be a test ensuring that you can break into the Trampoline and trace its code.

Ok, breakpoint not working with gdb-multiarch:

(gdb)target remote localhost:1234
(gdb)break CalcRAMSize
(gdb)continue

It just boots the Mac OS and only waits before continue.

I'm sure I'm doing something wrong here, maybe I need some PPC Libs installed, my host is X86.

[powermax]

Ok, breakpoint not working with gdb-multiarch:

(gdb)target remote localhost:1234
(gdb)break CalcRAMSize

Ugh, you need to break at memory addresses, not symbol names because the bundled Trampoline doesn't contain symbols!

Code: [Select]

(gdb)break *0x2025F4
is what you need but that will only work as soon as Trampoline code has been loaded into memory.

In order to break first time into the Trampoline, you'll need to set up a hardware breakpoint. If it works in your host, you're luck. If it doesn't work, you'll need to resort to another bag of tricks, for example, intercept the boot script or setting breakpoints at the OF client interface handler and then manually trace into the Trampoline code.

All this isn't fun at all but you've already agreed to get your hands dirty, so please go on

[ELN]

Patchpef (https://github.com/elliotnunn/patchpef) is a script that I hacked together to make small assembly-language patches to PEF files. Not at all pretty, but it was a big help in patching OS 9 to run on the Mac mini. It could pretty easily be adapted to insert arbitrary printfs into the Trampoline, as an alternative to debugger breakpoints.

[powermax]

Patchpef (https://github.com/elliotnunn/patchpef) is a script that I hacked together to make small assembly-language patches to PEF files.

Trampoline comes as ELF binary so we'd need to teach your script how to understand ELF first.

Patching existing binaries to inject debugging code can be very cumbersome and slow. Instrumented emulators are generally much better because they allow tracing code and analyzing its behavior much quicker than statical analysis tools (disassemblers). Armed with the right tool, spotting the issue in the binary code is often a question of few minutes...

[darthnVader]

Ok, here is what I have so far:


Qemu-PPC

Code: [Select]

qqemu-system-ppc64 -s -S -M mac99 -m 1024 -cpu ppc64 -hda ~/os9/os9.img -prom-env "aapl,debug=13FFF" -prom-env "fcode-debug?=true" -prom-env "auto-boot?=false" --nographic

>> =============================================================
>> OpenBIOS 1.1 [Feb 22 2018 07:53]
>> Configuration device id QEMU version 1 machine id 3
>> CPUs: 1
>> Memory: 1024M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,970FX
milliseconds isn't unique.
Welcome to OpenBIOS v1.1 built on Feb 22 2018 07:53

0 > boot Trying hd:,\\:tbxi...
>> switching to new context:
AAPL,debug bit settings (-OR- bits together):
       1 * = Print general informative messages.
       2 * = Print formatted Mac OS tables (except config/universal info).
       4 * = Print formatted config info table.
       8 * = Dump Mac OS tables (except config/universal info).
      10 * = Print node names while copying the device tree.
      20 * = Print property info while copying the device tree.
      40 * = Print interrupt-related info.
      80 * = Print interrupt tree traversal info.
     100 * = Print address resolution info.
     200 * = Print NV-RAM info.
     400 * = Print Mac OS "universal" info.
     800 * = Print "special" node info.
    1000 * = Load EtherPrintf utility via parcel for post FCode debugging.
    2000 * = Print BOOTP/DHCP/BSDP information.
    4000   = Allocate writable ROM aperture.
    8000   = Mark Toolbox image as non-cacheable.
   10000 * = Print parcel info while copying the device tree.
   20000   = Print information on device tree data checksums.
 1000000   = Enable the Nanokernel debugger.
 2000000   = Display the Nanokernel log during boot.
10000000   = Dont attempt to unhibernate system.
40000000   = Halt after end of FCode (useful if outputting to screen).

MacOS: RTAS not found.
work area logical address = 0x3FAD8000, physical address = 0x3FAD8000.
IsKeyDown: no keys held down


gdb-multiarch

Code: [Select]

gdb-multiarch
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".

warning: scripts/qemu-gdb.py: No such file or directory
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x0001f0ff00000000 in ?? ()
(gdb) break *0x2025f4
Breakpoint 1 at 0x2025f4
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0xf425200000000000 in ?? ()
(gdb)


Am I getting the proper breakpoint for our test?

[powermax]

Code: [Select]

Program received signal SIGTRAP, Trace/breakpoint trap.
0xf425200000000000 in ?? ()
(gdb)

Am I getting the proper breakpoint for our test?

What does

Code: [Select]

(gdb)disas $pc say when you hit the breakpoint?

Does the following command sequence work?

Code: [Select]

(gdb)display/i $pc
(gdb)stepi
You should be able to execute instruction by instruction and see the PPC Asm of the instruction to be executed next.

[darthnVader]

That didn't work, gdb-multiarch must be the wrong debugger, I'll see if I can figure how to setup PPC gdb.

Code: [Select]

gdb-multiarch
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".

warning: scripts/qemu-gdb.py: No such file or directory
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x0001f0ff00000000 in ?? ()
(gdb) break *0x2025f4
Breakpoint 1 at 0x2025f4
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0xf425200000000000 in ?? ()
(gdb) disas $pc
No function contains specified address.
(gdb) disas $pc
No function contains specified address.
(gdb) display/i $pc
1: x/i $pc
=> 0xf425200000000000:
    <error: Cannot access memory at address 0xf425200000000000>
(gdb) stepi

Program stopped.
0xf425200000000000 in ?? ()
1: x/i $pc
=> 0xf425200000000000:
    <error: Cannot access memory at address 0xf425200000000000>
Cannot access memory at address 0xf425200000000000
(gdb)


[darthnVader]

I built powerpc-linux-gdb, but I'm unsure I built it correct?

Code: [Select]

(gdb) disas $pc
No function contains specified address.
(gdb) display/i $pc
1: x/i $pc
=> 0x2025f8: stmw    r28,-16(r1)
(gdb) stepi
0x00000000002025fc in ?? ()
1: x/i $pc
=> 0x2025fc: stw     r0,8(r1)
(gdb)

It looks like maybe it's returning ppc assembly, Am I getting warmer?

[powermax]

That didn't work, gdb-multiarch must be the wrong debugger, I'll see if I can figure how to setup PPC gdb.

Did you try to invoke qemu-system-ppc64 with the "-g" option? Quoting https://reverseengineering.stackexchange.com/questions/8829/cross-debugging-for-arm-mips-elf-with-qemu-toolchain

In order to debug the binary with GDB, you need to launch qemu-mips so that it exposes a GDB stub, and connect from GDB.

Here another similar post: http://tinkering-is-fun.blogspot.com/2009/12/debugging-non-native-programs-with-qemu.html