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.
Regards, BALATON Zoltan