On Jan 27, 2018, at 9:41 AM, Programmingkid <address@hidden> wrote:
On Jan 27, 2018, at 9:34 AM, Jd Lyons <address@hidden> wrote:On Jan 27, 2018, at 8:41 AM, Programmingkid <address@hidden> wrote:
On Jan 27, 2018, at 7:33 AM, BALATON Zoltan <address@hidden> wrote:
On Sat, 27 Jan 2018, Jd Lyons via OpenBIOS wrote:Welcome to OpenBIOS v1.1 built on Jan 22 2018 11:12
0 > boot hd:10,\ppc\bootx >> switching to new context:
Mac OS X Loader
depthbytes isn't unique.
rowbytes isn't unique.
FILL-RECTANGLE isn't unique.
Opening partition [/address@hidden/address@hidden/address@hidden/address@hidden:10]...
HFSInitPartition: 2fc5b254
Loading HFS+ file: [\\com.apple.Boot.plist] from 2fc5b254.
setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
Reading HFS+ file: [\\mach_kernel] from 2fc5b254.
setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
non-root file owner detected: 501
Loading HFS+ file: [\System\Library\Caches\com.apple.kernelcaches\kernelcache.D57A14F7] from 2fc5b254.
Call Kernel!
FailToBoot: 6
ENTER
Excellent job with capturing Bootx's output.
So maybe you're looking for the problem at the wrong place when debugging BootX. It says it has transferred execution to the loaded kernel and it's the kernel which failed. Does the kernel version you're trying to boot support this CPU type at all?
Back when I would build the Mach kernel I would place a bunch of printf statements to see what it is doing. This is an easy way to debug the kernel. What version of Mac OS X are you currently trying to boot? If you want help with building and running a custom kernel just let me know.
Yes, I think a custom kernel maybe what’s needed, there is some magic that qemu-ppc is not doing. A custom kernel can boot on the 7448, as I have already confirmed. I was hoping to avoid that, but until someone that is familiar with how qemu-ppc boot OS X, I’ll just have to try the custom kernel route.
For the 7448, I used the kernel linked in these tread:
https://forums.macrumors.com/threads/os-x-tiger-on-a-603-604-cpu.1908276/
If we can figure out what changes were made that allowed qemu-ppc to boot with it, we should be able to figure out how to get the 7447a/7450/7455 to boot with it.
I never had any luck building mach_kernel, but I have’t tried in years, so you’ll have to walk me trough it.
I’ll ask LightBulbFun if he can get us a diff of his changes for 604 support, or at least give us an overview of how to add cpu support to the kernel.
There is still one thing I’d like to do with bootx, if you can help with that.
Changing kFailToBoot to 0 in include.tproj/sl.h will alter BootX’s default be- havior on error, so that it will return to Open- Firmware. Finally, calling Enter(), will cause BootX to drop back into the OpenFirmware User Interface. This can be used as a break point. The "dumpl" word will dump some memory, by en- tering the address, then the length, then "dumpl". By calling printf in BootX immediately before En- ter(), the address can be easily determined, and the variable can then be examined and altered from OpenFirmware. Finally typing the "go" command will resume BootX’s execution.
I don’t understand how, or where in the code to call Enter(), or printf?
All I changed was kFailToBoot to 0 in the sl.h. That was enough to get BootX to output some debug info for us, but if you say that we’re done with bootx when it calls the kernel( jumping to the memory where it loaded the kernel in real mode? ), then we can skip this.
I think dumpl isn't defined in OpenBIOS. dump is defined. From the description you send it sounds exactly like dump. I'm thinking defining dumpl like this might be of use to you:
: dumpl dump ;
Here was LightbulbFun’s reply:
"indeed I noticed that it lets OS X boot on QEMUs 7448 as well
and that OS X acts the same as it does on a 604 CPU (doing generic PPC rather then anything PPC750 7400 7450 or 970)
it makes me all the more eiger to get ahold of real 7448 hardware to play with (id like to know if the reason OS X wont boot on the 7448 option in QEMU is because the emulation is incompleat or if the 7448 really is not compatible with OS X)
here is the the pice of source code I modified https://mega.nz/#!YRBjiSDJ!7wGiXz49VaFl6i8UPn4VkZxyg9EPTt6cv0Z08CA7JZQ
its basically commenting out the line which says Bail/halt if unknown CPU, by commenting it out it no longer bails and continues to boot using the generic PowerPC config![:)]( "Smile :)")
(this is how it was up until the G5 build of 10.2.8 where they added the line to bail)
Apple still hosts the Darwin source code for almost every version of OS X
its well worth having a look through
like for example how Apple added Penryn support to 10.4.11 even tho the first Penryn macs shipped with 10.5”
and that OS X acts the same as it does on a 604 CPU (doing generic PPC rather then anything PPC750 7400 7450 or 970)
it makes me all the more eiger to get ahold of real 7448 hardware to play with (id like to know if the reason OS X wont boot on the 7448 option in QEMU is because the emulation is incompleat or if the 7448 really is not compatible with OS X)
here is the the pice of source code I modified https://mega.nz/#!YRBjiSDJ!7wGiXz49VaFl6i8UPn4VkZxyg9EPTt6cv0Z08CA7JZQ
its basically commenting out the line which says Bail/halt if unknown CPU, by commenting it out it no longer bails and continues to boot using the generic PowerPC config
Apple still hosts the Darwin source code for almost every version of OS X
its well worth having a look through
like for example how Apple added Penryn support to 10.4.11 even tho the first Penryn macs shipped with 10.5”
PK, I wonder why removing Bail/halt if unknown CPU doesn’t make the 7447a cpu boot this kernel.
Anyway, if you could give me so tips on building a new kernel, I’ll play around with it and see if I can get some more cpu’s in qemu-ppc to boot.