Re: [PATCH] target/ppc: Fix e6500 boot

[address@hidden]

From: "Cédric Le Goater" clg@kaod.org
To: "BALATON Zoltan" balaton@eik.bme.hu,"mario@locati.it" mario@locati.it
Cc: farosas@linux.ibm.com, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, 
danielhb413@gmail.com
Date: Sun, 26 Dec 2021 18:57:54 +0100
Subject: Re: [PATCH] target/ppc: Fix e6500 boot


On 12/25/21 22:53, BALATON Zoltan wrote:
> On Sat, 25 Dec 2021, mario@locati.it wrote:
>> I have tried to launch a freshly compiled qemu from git master on a NXP 
>> T2080RDB devkit that has a e6500 CPU in combination with a freshly compiled 
>> kernel 5.16-rc6
>> I have Debian SID ppc64 up and running using such a kernel, and when I 
>> launch qemu to run a VM with the same debian sid for ppc64 and the same 
>> kernel using --enable-kvm I end up with a kernel panic
 
Thanks for testing,
 
>> 
>> [....]
>> Run /sbin/init as init process
>> random: fast init done
>> systemd[1]: illegal instruction (4) at 3fff96562ac8 nip 3fff96562ac8 lr 
>> 3fff96562aa8 code 1 in libc-2.32.so[3fff96516000+1f7000]
 
debian ppc64 sid has a glibc 2.33 AFAICT
 
>> systemd[1]: code: 60000000 38600006 9122b7e8 4801bead 60000000 60000000 
>> 8122b7e8 2c090004
>> systemd[1]: code: 40820014 39200005 60000000 9122b7e8 <00000000> 60000000 
>> 8122b7e8 2c090005
> 
> Looks like it trips on a 0 opcode here in the middle of other values that 
> look like valid code so I wonder how that 0 got there? Did something 
> overwrite it before it tried to execute it? 
 
This looks like the abort() routine.
 
> If it always happens on the same address maybe you could try attaching gdb 
> and put a watch point on that address to see what writes there, otherwise I 
> don't know how to debug this.
 
Could you deduce the routine name from the nip ?
 
Thanks,
 
C.


 
I have updated  the guest VM but I get exactly the same result except that now 
I have libc-2.33.so installed.

[...]
VFS: Mounted root (ext4 filesystem) on device 254:0.
devtmpfs: mounted
Freeing unused kernel image (initmem) memory: 468K
This architecture does not have kernel memory protection.
Run /sbin/init as init process
random: fast init done
systemd[1]: illegal instruction (4) at 3fff8b7e615c nip 3fff8b7e615c lr 
3fff8b7e613c code 1 in libc-2.33.so[3fff8b799000+1fe000]
systemd[1]: code: 60000000 38600006 9122b7d0 4801bf19 60000000 60000000 
8122b7d0 2c090004 
systemd[1]: code: 40820014 39200005 60000000 9122b7d0 <00000000> 60000000 
8122b7d0 2c090005 
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
Rebooting in 180 seconds..

I don't know anything about debugging, sorry, just an average user here.
Currently asking for help to more expert users in the PowerProgressCommunity in 
order to understand what gdb is and how to use it but so far seems quite 
complicated, sorry.
It will taka a while before I will be able to provide what Zoltan is asking for.
If anybody of you want a remote ssh access to our devkit please send me an 
email privately.

Meanwhile, I successfully got a guest VM working with kvm simply by changing 
"-cpu e6500" into "-cpu e5500" and still using the same kernel I have compiled 
for the e6500, here the qemu commands I have used:

qemu-system-ppc64 -enable-kvm -M ppce500 -cpu e5500 -smp 4 -m 2G -net nic -net 
user -device virtio-vga -device virtio-mouse-pci -device virtio-keyboard-pci  
-drive format=raw,file=hdd_debian_ppc64_new.img,index=0,if=virtio -kernel 
uImage -append "root=/dev/vda rw"

And here a screenshot I took of the guest machine up and running quite well
https://repo.powerprogress.org/t2080rdb/qemu/2021-12-27_qemu_e6500_kvm_kind_of_working.jpg

What I find strange and that leave me puzzled is that running hardinfo the cpu 
is reported as an e6500 with altivec and not an e5500 that does not have 
altivec.