GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
Moderators: Cat_7, Ronald P. Regensburg
- adespoton
- Forum All-Star
- Posts: 4286
- Joined: Fri Nov 27, 2009 5:11 am
- Location: Emaculation.com
- Contact:
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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.
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.
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
Just today, I've started getting a system bomb of error type 11 during startup. It happens wirth the following command line:
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)?
But if I omit the second drive argument, it starts up fine../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
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)?
- adespoton
- Forum All-Star
- Posts: 4286
- Joined: Fri Nov 27, 2009 5:11 am
- Location: Emaculation.com
- Contact:
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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.
-
- Mac Mechanic
- Posts: 169
- Joined: Mon Aug 29, 2016 3:44 am
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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)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.
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.
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".
-
- Apple Corer
- Posts: 243
- Joined: Sun Jan 31, 2016 6:01 pm
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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
- 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
-
- Student Driver
- Posts: 20
- Joined: Fri Jan 06, 2017 10:02 pm
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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
(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.
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
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
If you want to run Public Beta, make sure to spoof the clock!
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):
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.
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
Sorry for the long post—have a picture!
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;
}
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'
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
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
Code: Select all
-rtc base="2000-09-14",clock=vm
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
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):
Sorry for the long post—have a picture!
Last edited by steventroughtonsmith on Sun Jan 08, 2017 2:03 am, edited 1 time in total.
-
- Apple Corer
- Posts: 243
- Joined: Sun Jan 31, 2016 6:01 pm
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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: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.
/* [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?
That's so Steve. Do you miss Carbon?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.
-
- Mac Mechanic
- Posts: 169
- Joined: Mon Aug 29, 2016 3:44 am
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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.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).
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.
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
Not removed per se. It just so happens that cocoa.m includes this line:Programmingkid wrote: I wasn't aware of any Carbon calls in the Cocoa.m file. What functions do you want to see removed?
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?#include <Carbon/Carbon.h>
AFAIK, it doesn't use any Carbon functionality...
- Madd the Sane
- Student Driver
- Posts: 15
- Joined: Fri Aug 31, 2012 6:27 pm
- Location: Idaho
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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!
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
Now that makes sense!Madd the Sane wrote:The key codes used by the system are mapped to defines found in Carbon
-
- Mac Mechanic
- Posts: 169
- Joined: Mon Aug 29, 2016 3:44 am
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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.
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.
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
Nice! Hope to get this in QEMU, not QEMU MANAGER Any way of how to because i'm still a little confused.
-
- Mac Mechanic
- Posts: 169
- Joined: Mon Aug 29, 2016 3:44 am
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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:
Mouse/keyboard seem to work correctly when switchig fullscreen/windowed modes(Tried in Panther).Thank you for your work!
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);
Last edited by alex195812 on Tue Jan 10, 2017 8:43 am, edited 5 times in total.
- adespoton
- Forum All-Star
- Posts: 4286
- Joined: Fri Nov 27, 2009 5:11 am
- Location: Emaculation.com
- Contact:
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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.
And this OpenBIOS needs your custom qemu build, so someone would need to compile him a Windows target.
-
- Mac Mechanic
- Posts: 169
- Joined: Mon Aug 29, 2016 3:44 am
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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.
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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.
-
- Mac Mechanic
- Posts: 169
- Joined: Mon Aug 29, 2016 3:44 am
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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.
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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
Last edited by Meow_2004 on Tue Jan 10, 2017 4:15 pm, edited 1 time in total.
-
- Mac Mechanic
- Posts: 169
- Joined: Mon Aug 29, 2016 3:44 am
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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!
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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) It will be a bit before I can, I'll take a screenshot, and post it once I get it!
!
!
-
- Student Driver
- Posts: 20
- Joined: Fri Jan 06, 2017 10:02 pm
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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:
And replacing those first 8 bytes with:
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
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
Code: Select all
38 60 00 00 4E 80 00 20
- adespoton
- Forum All-Star
- Posts: 4286
- Joined: Fri Nov 27, 2009 5:11 am
- Location: Emaculation.com
- Contact:
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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.
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
@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?
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?