[OpenBIOS] testing Max OS X boot on latest trunk (revision 1085) + divide by zero patch

[Mark Cave-Ayland]

On 12/01/13 16:05, Amadeusz Sławiński wrote:

> I used the latest proposed divide by zero patch
>
> So it seems like it is almost there.
>
> Seems like it still can't load kernel when run with boot cd:,\\:tbxi
> Mac OS X 10.0
> http://asmblr.net/scrot/2013-01-12-155737_1366x768_scrot.png
>
> Mac OS X 10.2
> http://asmblr.net/scrot/2013-01-12-155642_1366x768_scrot.png
>
> Mac OS X 10.4
> http://asmblr.net/scrot/2013-01-12-155935_1366x768_scrot.png
>
>
> However when I specify partition to use it loads:
> Mac OS X 10.0 (boot cd:9,\\:tbxi)
> http://asmblr.net/scrot/2013-01-12-163133_1366x768_scrot.png
>
> Mac OS X 10.2 (boot cd:9,\\:tbxi)
> http://asmblr.net/scrot/2013-01-12-163300_1366x768_scrot.png
>
> Mac OS X 10.4 (boot cd:3,\\:tbxi)
> http://asmblr.net/scrot/2013-01-12-163419_1366x768_scrot.png

This should now be fixed in SVN trunk.

I believe I have now committed all outstanding patches based upon 
William's main GSOC patchset, and performed a QEMU CDROM boot test 
across all of SPARC32, SPARC64 and PPC to confirm that I haven't 
introduced any regressions across any of my test images. Thank you 
everyone for your help, patience and testing.

Interestingly enough, commits 1081 and 1082 appear to have fixed the key 
issues with OpenBIOS's PPC MMU code and as a result, the following 
kernels will now at least boot from ISO images in QEMU:

Darwin
FreeBSD
NetBSD
HelenOS
Fedora Linux
SuSE Linux

I think the remainder of the bugs during kernel initialisation are 
related to either missing/erroneous properties in the OpenBIOS device 
tree, or bugs in QEMU's device emulation/Mac hardware model. This will 
likely require some assistance from the QEMU people to fix.


ATB,

Mark.