qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jd Lyons
Subject: Re: [Qemu-ppc] [OpenBIOS] Apple's BootX
Date: Sun, 28 Jan 2018 06:58:47 -0500


> On Jan 27, 2018, at 7:50 PM, BALATON Zoltan <address@hidden> wrote:
> 
> On Sat, 27 Jan 2018, Jd Lyons via OpenBIOS wrote:
>> I’m unable to boot openbios on TCG with the 7447a, 7450, 7455, or the 750fx, 
>> even tho I’ve added support for them. Not sure the issue there.
>> 
>> However Openbios will boot with KVM with the -cpu 7447a, 7450, and 7455.
> 
> I'm not sure what could cause this but it seems to be an OpenBIOS problem if 
> if cannot start on other 74xx CPUs than the default 7400.
> 
>> With -enable-kvm -cpu host, Debian install, runs and boots fine, no issues, 
>> other than the L2 cache is not active, but that an issue with openbios, and 
>> I’m not sure how to deal with that yet. Maybe just enable it in software 
>> while the OS is running, maybe add the code to Openbios, that if it detects 
>> the hypervisor it should enable the L2/L3.
> 
> I don't know how KVM works but do you need to enable L2/L3 caches in the 
> guest OS as well? Isn't the host kernel that enables it when it boots, then 
> it should be working even if the guest does not know about it? (I mean what 
> counts is the caches of the physical CPU, what the guest sees or thinks 
> likely does not matter for speed so this may be only a cosmetic problem.) 
> Maybe adding the info about caches to the device tree could let the guest 
> know that there are some caches and make something to think they are enabled 
> but not sure about it an if this would help other than seeing caches enabled 
> in the guest.
> 
>> On that note, my patch to qemu for 7447a v1.5 is incomplete, it doesn’t show 
>> up in the list of CPU’s when I invoke -cpu help, and I can’t chose -cpu 
>> 4747a_v1.5.
>> 
>> Do you know where in the sconce code that list is propagated, I need to 
>> patch that too?
> 
> I don't know, try searching for 7447a and see where it pops up and then 
> search for the structures it's defined in to see where those are used.
> 
>> How would I enable -d in the in_asm debug options?
>> 
>> Is it a runtime option, or do I need to enable it when I build?
> 
> It's a normal command line option. See 'qemu-system-ppc -d help'. Other 
> interesting options are int,unimp,guest_errors (although on PPC maybe only 
> int does something). I've tried if qemu-system-ppc gets to OpenBIOS prompt 
> with 'qemu-system-ppc -cpu G4 -d int' and 'qemu-system-ppc -cpu 7447a -d int' 
> and I see it takes different exceptions in these cases:
> 
> $ ppc-softmmu/qemu-system-ppc -d int
> Raise exception at fff08978 => 00000003 (40000000)
> Raise exception at fff2a380 => 00000003 (40000000)
> Raise exception at fff2a380 => 00000002 (00)
> Raise exception at fff2a384 => 00000002 (00)
> [and so on]
> 
> $ ppc-softmmu/qemu-system-ppc -cpu 7447a -d int
> Raise exception at fff08978 => 0000004e (00)
> [hangs here]
> 
> With adding in_asm you can see that at first exception G4 goes to:
> 
> 0x00000400:  48002028  b        0x2428
> 
> which is ISI, that is OK and handled in OpenBIOS,
> but with the 7447a it goes to
> 
> 0x00001000:  4bfff105  bl       0x104
> 
> which is "implementation specific", not sure what it means for 7447a and 
> likely unhandled in OpenBIOS. Indeed, as I see it's defined as: 
> ILLEGAL_VECTOR( 0x1000 ) in openbios/arch/ppc/qemu/start.S which goes to 
> trap_error which is supposed to call unexpected_excep() that is supposed to 
> print "openbios panic" (in openbios/arch/ppc/qemu/init.c) but probably it's 
> too early for printk to work so the message was not displayed.
> 
> That's what I could figure out but not sure where to go from here. You should 
> find out what is 0x1000 exception on 7447a and why is it fired here and how 
> to avoid or handle it in OpenBIOS.
> 

Did you patch Openbios to support the 7447a?

If not you’re likely getting the unknown PVR message, and Openbios will halt.

> Regards,
> BALATON Zoltan


Thanks Balaton, I’ll see what info I can yield from -d.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]