GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

About Qemu-system-ppc, a PPC Mac emulator for Windows, macOS and Linux that can run Mac OS 9.0 up to Mac OS X 10.5

Moderators: Cat_7, Ronald P. Regensburg

User avatar
adespoton
Forum All-Star
Posts: 4226
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by adespoton »

Makes sense. I haven't figured out yet whose branch he was using. Ben's patch would be nice.

Interesting bit about SM 0 A9F4 G 0 -- this was for 24-bit ROMs. When Apple re-architected, the new design sometimes dumped legitimate data at address 0, so the "more modern" command beginning around 1992-1993, was SM FA700 (this address was generally supposed to be fine to overwrite) A9F4 <cr> PC FA700 G

This used more modern MacsBug commands in a manner that should work across more architectures; in reality, SM 0 often resulted not in "exit to shell" being executed, but in the Application stack finding unexpected content at address 0 and bailing (or sometimes just locking up).

I was really annoyed that Jobs basically pulled the plug on G5 in general right when it was looking interesting. But I guess by that point they already knew they were going x86.
WizKid
Tinkerer
Posts: 72
Joined: Sun Jul 31, 2016 11:58 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by WizKid »

Just today, I've started getting a system bomb of error type 11 during startup. It happens wirth the following command line:
./qemu-system-ppc-scr-vga -bios ./openbios-qemu-scr-sungem.elf -boot c -M mac99 -cpu G3 -m 512 -prom-env 'auto-boot?=true' -prom-env 'boot-args=-v' -netdev user,id=network0 -device sungem,netdev=network0 -device usb-mouse -device usb-kbd -drive file=macos9.raw,format=raw,media=disk,cache=writethrough -drive file=iso/Mac/CDs/macos-922.iso,format=raw,media=cdrom
But if I omit the second drive argument, it starts up fine.

And this is even before extensions load. I get it at the gray startup screen when the "Welcome to Mac OS" screen appears. The bomb appears over said screen.

I don't think MacsBug loads that early. Unimplemented FPU instruction(s)?
User avatar
adespoton
Forum All-Star
Posts: 4226
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by adespoton »

Sounds like just before MacsBug initializes. In NVRAM territory maybe? I think that's about where time gets loaded and networking is initialized. That's where we were getting crashes back when we were using the customized OS 9 boot CD to boot 2.7pre last year, and the traces indicated networking and serial communications. It's somewhere back in this thread :D
WizKid
Tinkerer
Posts: 72
Joined: Sun Jul 31, 2016 11:58 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by WizKid »

I've figured out if I specify the drive arguments before the usb device arguments, it causes the system bomb. But if specify them before said arguments, it doesn't.
alex195812
Mac Mechanic
Posts: 169
Joined: Mon Aug 29, 2016 3:44 am

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by alex195812 »

The only problem is that the zip file posted above (if that is indeed his local repository) is not a valid git repository according to SmartGit (a Java git client).

Sure, one could do 'git init' on the repo and create one, but the changes as compared to 2.8.0 wouldn't be logged as commits.
Yes,the repo was downloaded as zip,not git-cloned.For user purposes it never mattered with qemu.Though I think it's not a great problem for I keep all modifyed files separately and once github repository (2.8.0 based) was open the changes could be done as Adespoton described.Though thus it will be "summarized changes" while partly they are ozbenh's and partly mcayland's or ProgrammingKid's.I just combined them.Is it right not to mention it? The real problem(for me) is that I wouldn't like to do it for it needs maintaining,in which I have no experience.And I have a little more than null programming skills.Maybe someone else could do it?For it could live without me if I get too involved in something else(I think about some goals like PearPC,Xenia,RPCS3 and others)
For openbios I used mcayland repo which is "1 commit ahead of openbios:master".Once I posted (as a zipped folder) my modifyed repo,that is no problems with that,too.
Yesterday I tried to boot 9.04 with original mcayland build and got "system error occured...Apple Audio Extension...Illegal isruction...if you want to disable...". With moved Apple Audio Extension it boots.No sound of course.But this doesn't work with Ben's(when using his openbios with added by me screamer support) or my build.Looks like OS 9.0 doesn't like screamer. :smile:
Checked again with original mcayland build.Boots(with Aplle Audio Extention moved).Place the extension to its place.Boots!Try several times.Boots with sound working.Change the order in command line(-cpu and -device usb-mouse now before -drive entry)."System Error..."Return to previous order."System Error" all the same.Several times.What the ...?
And again,move the extension,boot,return it to its place,reboot.Works with sound.
My build just hangs on "Mac OS 9 Starting up".
Programmingkid
Apple Corer
Posts: 243
Joined: Sun Jan 31, 2016 6:01 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Programmingkid »

Made a version 3 of my super cocoa.m file. The changes are:
- Eliminated stuck key issue with using the fullscreen menu
- Eliminated stuck key issue when holding down a key then letting go of the key while a menu was displayed
- Added ability to stop a paste at any time by displaying a stop button during pasting

Most stuck key issues have been eliminated. If you do find a repeatable situation where stuck key happens, please let me know.

http://www.mediafire.com/file/247u52aky ... file_3.zip
steventroughtonsmith
Student Driver
Posts: 20
Joined: Fri Jan 06, 2017 10:02 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by steventroughtonsmith »

Hi all,

Amazing progress on qemu-ppc in the past year.

I've been playing around with this for the past couple of days, figuring out how to boot Mac OS X Server and Developer Previews 1 through 4. This is a brain dump of everything I've come up against, just in case it's of use to anybody here.

To boot OS X Server and DP1 you need a modified OpenBIOS that removes the partition valid check. I recompiled https://github.com/mcayland/openbios/tree/screamer using the ppc-elf toolchain at http://awos.wilcox-tech.com/downloads/AWOS-CC.bz2 (decompresses to a dmg).

packages/mac-parts.c

Code: Select all

 if(! ((__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsValid) &&
			(__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsAllocated) &&
			(__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsReadable)) ) {
		DPRINTF("Partition %d is not valid, allocated and readable\n", parnum);
			//goto out;
	    }
(You can also byte-patch the install ISOs if you prefer, Byte @ 5723, -> "0x77"; TL;DR the UFS install partitions do not have valid flags, which is why OpenBIOS gives you a broken system folder icon if you try)

Mac OS X DP1 also has a model check that g3beige will fail, which you can spoof in Open Firmware.

Code: Select all

-prom-env 'boot-command=dev / " PowerMac1,1" encode-string " model" property " PowerMac1,1" encode-string " MacRISC" encode-string encode+ " Power Macintosh" encode-string encode+ " compatible" property boot cd:9,\\:tbxi'
Both OS X Server and DP1 require a pre-partitioned target disk to install onto; the layout & filesystems are important. I threw together a script to do that automatically https://gist.github.com/steventroughton ... 0cfa9e5936

Code: Select all

#!/bin/sh

TARGET_IMAGE=1G_BLANK_MACOSX_DP1_DISK_IMAGE.img

DISKSIZE_IN_BLOCKS=2097152
PRIMARY_PARTITIONSIZE_IN_BLOCKS=`expr $DISKSIZE_IN_BLOCKS - 512 - 16384 - 64`

pdisk $TARGET_IMAGE -initialize
pdisk $TARGET_IMAGE -createPartition MOSX_OF3_Booter Apple_HFS 64 16384
pdisk $TARGET_IMAGE -createPartition SecondaryLoader Apple_Loader 16448 512
pdisk $TARGET_IMAGE -createPartition "0x00 0x00 0x00" Apple_Rhapsody_Inst 16960 $PRIMARY_PARTITIONSIZE_IN_BLOCKS
DP1's first boot can't find the installer packages—I haven't figured this one out yet (I think it's related to the partition name, which tells the installer what packages/languages to pick), but you can work around it by booting in single user mode and swapping /System/Administration/Installer.app/Installer with a script that calls the original binary and points it to /Disk/System/Installation/Packages/OSInstall.mpkg. Once installed, restore Installer.app to the way it should be, and touch /var/log/OSInstall.custom to inform the OS that it should go to the Assistant next boot instead of Installer.

Developer Preview 2 onwards are comparatively trivial to install. If you want to see the BootX screen as intended, boot qemu with

Code: Select all

-g 1024x768x8
If you want to run Public Beta, make sure to spoof the clock!

Code: Select all

-rtc base="2000-09-14",clock=vm
Mac OS X Server 1.x is fully working, but doesn't recognize keyboard/mouse input, so while you can install and boot it, you can't get through the setup assistant. It also seems to hang at boot for me if you give it an emulated USB mouse device.

For all the above, the drive order can be important for the boot settings to register as valid. I'm doing it like so, and swapping the drive index when necessary; OS X Server also sometimes needs you to manually specify the root device (hd0 or sd0):

Code: Select all

-prom-env 'boot-args=-v rd=sd0' -prom-env 'boot-device=cd:9,\\:tbxi' -drive file=Mac_OS_X_Server_1.2-1G.img,index=1,format=raw,media=disk -drive file=Mac_OS_X_Server_1.2_Pele1Q10.iso,index=0,format=raw,media=cdrom
To figure out which partitions you want to boot, you can use 'pdisk'. MOSX_OF3_Booter is your target, every time—it loads BootX from HFS which can then go find where OS X is installed and jump to mach_kernel.

Code: Select all

pdisk /Applications/PearPC/10.0DP1-TEST-1G.img 
Edit /Applications/PearPC/10.0DP1-TEST-1G.img -
Command (? for help): p

Partition map (with 512 byte blocks) on '/Applications/PearPC/10.0DP1-TEST-1G.img'
 #:                type name                        length   base    ( size )
 1: Apple_partition_map Apple                           63 @ 1      
 2:           Apple_HFS MOSX_OF3_Booter              16384 @ 64      (  8.0M)
 3:        Apple_Loader SecondaryLoader               1024 @ 16448  
 4:           Apple_UFS Mac OS X Dev. Preview 5/99 2079680 @ 17472   (1015.5M)

Device block size=512, Number of Blocks=2097152 (1.0G)
DeviceType=0x0, DeviceId=0x0

Command (? for help): 
I've been tweeting through this for the past couple days at https://twitter.com/stroughtonsmith, so apologies if this is a little brain-dump-y. I hope it helps a little. Disclaimer to all the above: I don't really know what I'm doing, but I'm having fun :lol:

Sorry for the long post—have a picture!

Image
Last edited by steventroughtonsmith on Sun Jan 08, 2017 2:03 am, edited 1 time in total.
Programmingkid
Apple Corer
Posts: 243
Joined: Sun Jan 31, 2016 6:01 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Programmingkid »

WizKid wrote: Another wish would be to get rid of all the Carbon calls in 'cocoa.m' and to add the patch 'ppc-Add-programmer-switch-hooked-up-to-NMI.patch' from ozbenh's branch so we could enter MicroBug to get out of tough situationsm short of a hard shutdown by quoting qemu due do a corrupt pointer stack.
We can already get into macsbug by using the Send Key menu if you use my cocoa.m file. Without it, to enter into macsbug, just push Command-Power. The power key needs to be enabled in the cocoa.m file. This is what it looks like:
/* [kVK_F1] = Q_KEY_CODE_POWER, */

[kVK_F1] = Q_KEY_CODE_F1,

Remove the comments for the Q_KEY_CODE_POWER, and comment out the Q_KEY_CODE_F1 line. Macsbug would be accessible by pushing Command-fn-F1 if you are using an Apple keyboard. It might be just Command-F1 otherwise.

I wasn't aware of any Carbon calls in the Cocoa.m file. What functions do you want to see removed?
WizKid wrote: As a side note. remember how 64-bit Carbon was ready to ship but was killed at the last minute by Jobs? Cook would have never ordered that to happen.
That's so Steve. Do you miss Carbon?
alex195812
Mac Mechanic
Posts: 169
Joined: Mon Aug 29, 2016 3:44 am

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by alex195812 »

To boot OS X Server and DP1 you need a modified OpenBIOS that removes the partition valid check. I recompiled https://github.com/ozbenh/openbios using the ppc-elf toolchain at http://awos.wilcox-tech.com/downloads/AWOS-CC.bz2 (decompresses to a dmg).
Oh,it's good,thanx for info and script.I have found a way to install DP1 and Server some "twisted" way(wrote about it a month ago),but "vanilla' installation is much better surely.Will try your sollution sometime later.

I still think about Mac OS 9 boot bug in my build and found that it always happens within conjunction of screamer-enabled openbios & vga-enabled qemu.It looks like on earliest boot stages screamer occupies some resources(memory areas,irq's,don't know yet) that external vga driver wants later during OS boot.The code for loading vga driver is also in openbios.For some reason the conflict affects only OS 9 booting,especially(but not excusively) with G3 cpu.Need more detailed diagnosis to heal it.I think qemu binary is OK,some changes needed in openbios only.

@ProgrammingKid thanx,have downloaded the file,will try it when this unpleasant boot bug is fixed.
WizKid
Tinkerer
Posts: 72
Joined: Sun Jul 31, 2016 11:58 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by WizKid »

Programmingkid wrote: I wasn't aware of any Carbon calls in the Cocoa.m file. What functions do you want to see removed?
Not removed per se. It just so happens that cocoa.m includes this line:
#include <Carbon/Carbon.h>
Why does it import the Carbon/HIToolbox headers? If possible, wouldn't it be logical to remove all calls to the (now long deprecated) Carbon API?

AFAIK, it doesn't use any Carbon functionality...
User avatar
Madd the Sane
Student Driver
Posts: 14
Joined: Fri Aug 31, 2012 6:27 pm
Location: Idaho

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Madd the Sane »

The key codes used by the system are mapped to defines found in Carbon.
Get out of my mind, idea! I already have an idea in there!
WizKid
Tinkerer
Posts: 72
Joined: Sun Jul 31, 2016 11:58 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by WizKid »

Madd the Sane wrote:The key codes used by the system are mapped to defines found in Carbon
Now that makes sense! :mrgreen: :shock:
alex195812
Mac Mechanic
Posts: 169
Joined: Mon Aug 29, 2016 3:44 am

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by alex195812 »

A version of openbios patched accordig to @steventroughtonsmith:
https://drive.google.com/open?id=0B69bs ... mdIa2t0Um8
Can boot and install unmodifyed DP1 and Server 1.2 as decribed above by Steven.Though I suppose it still has that OS9 boot bug.Haven't yet found a way to resolve it.Someone more skilled is needed. :smile:
User avatar
Meow_2004
Granny Smith
Posts: 108
Joined: Thu Jan 05, 2017 6:24 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Meow_2004 »

Nice! Hope to get this in QEMU, not QEMU MANAGER :) Any way of how to because i'm still a little confused.
alex195812
Mac Mechanic
Posts: 169
Joined: Mon Aug 29, 2016 3:44 am

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by alex195812 »

This is for use with qemu version I posted Jan 03 instead of included openbios.

Well,I thought as IMO qemu itself is OK,no need to wait till openbios is fixed and here is a version with more extended cocoa3 ui:
https://drive.google.com/open?id=0B69bs ... jZxRkROeVU
For booting/installing OS 9.0 openbios-wip version(w/o screamer) may be used.Maybe someday I'll see how to resolve resource conflict between screamer and vga or someone smarter will pay attention to it...

For @ProgrammingKid Some new warnings appear while building:

Code: Select all

ui/cocoa.m:1612:9: warning: 'NSRunAlertPanel' is deprecated: first deprecated in OS X 10.10 - Use
      NSAlert instead [-Wdeprecated-declarations]
        NSRunAlertPanel(@"Alert", @"No real optical media found.", @"OK", nil, nil);
        ^
/System/Library/Frameworks/AppKit.framework/Headers/NSPanel.h:48:25: note: 'NSRunAlertPanel' has
      been explicitly marked deprecated here
APPKIT_EXTERN NSInteger NSRunAlertPanel(NSString *title, NSString *msgFormat, NSString *defa...
                        ^
ui/cocoa.m:1734:24: warning: sending 'id<NSFileManagerDelegate>' to parameter of incompatible type
      'id<NSMenuDelegate>'
    [menu setDelegate: [NSApp delegate]];
                       ^~~~~~~~~~~~~~~~
/System/Library/Frameworks/AppKit.framework/Headers/NSMenu.h:147:39: note: passing argument to
      parameter 'delegate' here
@property (assign) id<NSMenuDelegate> delegate;
                                      ^
ui/cocoa.m:1818:24: warning: sending 'QemuCocoaAppController *' to parameter of incompatible type
      'id<NSFileManagerDelegate>'
    [NSApp setDelegate:appController];
                       ^~~~~~~~~~~~~
/System/Library/Frameworks/Foundation.framework/Headers/NSFileManager.h:109:47: note: passing
      argument to parameter 'delegate' here
@property (assign) id <NSFileManagerDelegate> delegate NS_AVAILABLE(10_5, 2_0);
Mouse/keyboard seem to work correctly when switchig fullscreen/windowed modes(Tried in Panther).Thank you for your work! :smile:
Last edited by alex195812 on Tue Jan 10, 2017 8:43 am, edited 5 times in total.
User avatar
adespoton
Forum All-Star
Posts: 4226
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by adespoton »

I believe Meow_2004 is using Windows 10? Your builds are for OS X, right?

And this OpenBIOS needs your custom qemu build, so someone would need to compile him a Windows target.
alex195812
Mac Mechanic
Posts: 169
Joined: Mon Aug 29, 2016 3:44 am

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by alex195812 »

Oh,guess it's so then.I've never tried to build qemu on Windows.I wonder if it could be built on wine...I used qemu windows builds on wine in Mac OS sometimes.
User avatar
Meow_2004
Granny Smith
Posts: 108
Joined: Thu Jan 05, 2017 6:24 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Meow_2004 »

Yes, I do use Window 10, but I need to check the version first. It may be a bit though, also to get the openbios for dp1, does it use linux? Or can you still get it in Windows.
alex195812
Mac Mechanic
Posts: 169
Joined: Mon Aug 29, 2016 3:44 am

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by alex195812 »

Openbios can work of course with windows builds but to boot successfully DP1 you need vga patch applied to Old World which is missing in known windows qemu builds.But you may compile your own build from source I posted on Jan 05.I haven't yet learned to make windows builds myself.
User avatar
Meow_2004
Granny Smith
Posts: 108
Joined: Thu Jan 05, 2017 6:24 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Meow_2004 »

ummmmmmmmm, yeaaaaa i kind-of know a bit about coding certain areas, but not as much, I don't have to get DP1, i'm mainly focusing on getting DP3, 4, and Public Beta, and maybe DP2. Also I can get the Rhapsody too, because of the Intel version too. It would be cool if we can figure out the ppc version :) :lol: :idea:
Last edited by Meow_2004 on Tue Jan 10, 2017 4:15 pm, edited 1 time in total.
alex195812
Mac Mechanic
Posts: 169
Joined: Mon Aug 29, 2016 3:44 am

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by alex195812 »

DP2 and DP3 work in qemu since July/August;to make DP4 work just attach installation image as a hard disk and boot to it.Rhapsody and Mac OS X Server cannot currently be really used because of keyboard/mouse not working.About "canonical windows builds" see http://www.emaculation.com/forum/viewto ... =34&t=9028 Good luck! :smile:
User avatar
Meow_2004
Granny Smith
Posts: 108
Joined: Thu Jan 05, 2017 6:24 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Meow_2004 »

Yes! Hoping to get it! But which build? I think I have the 64-bit qemu download, but anyway. Can you give me a code sample? Or is it with the download? (Yea, i'm one of those people who don't look at all the files) :lol: It will be a bit before I can, I'll take a screenshot, and post it once I get it!
!
steventroughtonsmith
Student Driver
Posts: 20
Joined: Fri Jan 06, 2017 10:02 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by steventroughtonsmith »

Addendum to my earlier post, turns out Server 1.0 et al can be booted; I believe the reason they do not is because when mach goes to identify_machine(), it can't find a bunch of devices that it expects to be there in the openfirmware devicetree, and panic()s on each one it can't find, but I could be wrong.

You can NOP out panic() in the ISO by searching for:

Code: Select all

7C 08 02 A6 93 61 FF EC 93 81 FF F0 93 A1 FF F4 93 C1 FF F8 93 E1 FF FC 90 01 00 08 94 21 FE A0 7C 7C
And replacing those first 8 bytes with:

Code: Select all

38 60 00 00 4E 80 00 20
Now it will ignore kernel panics—this will be enough to get you booted to userland. Yes this is a nasty nasty workaround until a better way can be figured out :shock:

Image
User avatar
adespoton
Forum All-Star
Posts: 4226
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by adespoton »

If we can trace what devices it is looking for in the tree, we can set up dummy devices in OpenBIOS -- if your panic patch works, then that indicates this should also work, and should even be doable via an OF line or two. So the next task is to find and document what OF devices the kernel is polling :) As we find them, we can just add them in as OF command-line arguments until we're sure we've covered all bases, and then move the entire dummy tree into OpenBIOS -- with appropriate mappings to virtual devices in qemu if possible.
mcayland
Mac Mechanic
Posts: 152
Joined: Sun Nov 01, 2015 10:33 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by mcayland »

@steventroughtonsmith: have just been catching up on your posts (and Twitter feed!) to see the work you have been doing - amazing!

As OpenBIOS maintainer can I encourage you to submit your patches to the OpenBIOS mailing list with appropriate SoBs so we can try and upstream your work? :)
Post Reply