Re: [Qemu-ppc] [OpenBIOS] Apple's BootX

[Programmingkid]

> 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 ;