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

[Amadeusz Sławiński]

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

There is also another patch which I think I forgot to mention but it
makes kernel boot further on older versions:
https://lists.nongnu.org/archive/html/qemu-devel/2011-08/msg01418.html
it fakes frequencies of some hardware

Mac OS X 10.0
http://asmblr.net/scrot/2013-01-12-164304_1366x768_scrot.png

Mac OS X 10.2
http://asmblr.net/scrot/2013-01-12-164529_1366x768_scrot.png

Mac OS X 10.4 (looks same as without)
http://asmblr.net/scrot/2013-01-12-164738_1366x768_scrot.png

Amadeusz

[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

I have a patch for this, but it's based upon a refactored version of the 
partition parsing code which I haven't applied yet. Basically the fix is 
that if you're autochoosing a partition to boot from, make sure you 
explicitly add the found partition found into the bootpath property. 
Otherwise BootX falls back to its default behaviour which is to scan the 
first 3 partitions on the device.
> There is also another patch which I think I forgot to mention but it
> makes kernel boot further on older versions:
> https://lists.nongnu.org/archive/html/qemu-devel/2011-08/msg01418.html
> it fakes frequencies of some hardware
>
> Mac OS X 10.0
> http://asmblr.net/scrot/2013-01-12-164304_1366x768_scrot.png
>
> Mac OS X 10.2
> http://asmblr.net/scrot/2013-01-12-164529_1366x768_scrot.png
>
> Mac OS X 10.4 (looks same as without)
> http://asmblr.net/scrot/2013-01-12-164738_1366x768_scrot.png

Ooooh I missed that one. Given that the values should be passed from 
QEMU then perhaps the values in hardware definitions held within QEMU 
are incorrect. Alex?

ATB,

Mark.

[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.

[Andreas Tobler]

On 13.01.13 16:43, Mark Cave-Ayland wrote:
> 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.

I can confirm the statement from Mark regarding FreeBSD. So far I can
boot but I fail due to the fact that some interrupt-parents are not
populated. Namely for via-cuda and for ata-1/2/3. Adding these lets the
boot continue until I hang somewhere in a cpu_idle routine. Still
investigating.

One thing the qemu people might clarify, is -M mac99 ok to use? Or what
would be the preferred Mac model and which cpu?
My trials go with mac99 and -cpu G4 on the 32-bit qemu.

I think once I solved the spinning in the cpu_idle routine I'm near
completing the boot.

Thank you all for this effort!

Andreas

testing Mac OS X boot on latest trunk (revision 1085) + divide by zero patch

[Programmingkid]

On Jan 12, 2013, at 11:05 AM, Amadeusz Sławiński wrote:
> There is also another patch which I think I forgot to mention but it
> makes kernel boot further on older versions:
> https://lists.nongnu.org/archive/html/qemu-devel/2011-08/msg01418.html
> it fakes frequencies of some hardware

I also was able to make Mac OS 10.0 boot further with this patch. It stops because of some problem with the trap at 0x400 (ISI exception).