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

[BALATON Zoltan]

Hello,

On Mon, 27 Dec 2021, mario@locati.it wrote:
> 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.

Maybe it's not needed, it was just an idea to get closer to the problem 
but you could also try finding this our from within the VM as Cedric 
suggested. As for attaching gdb to QEMU for debugging guest code here's an 
article but maybe you can find a better one elsewhere too:

http://nickdesaulniers.github.io/blog/2018/10/24/booting-a-custom-linux-kernel-in-qemu-and-debugging-it-with-gdb/

Do you have the libc-2.33.so binary with debugging symbols? (Maybe it's 
available in some debug package, I don't know how Debian handles this.) If 
so you could try to check what is at the offset shown in the log (I think 
it's 1fe000 above) either with gdb or objdump or maybe there are other 
ways as well.

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

With KVM the code is run on the host CPU so depending on how it determines 
the CPU model you may still get the host CPU. I'm not sure what -cpu does 
with KVM but apparently it does something if it makes it boot. Probably 
libc takes a different path with these CPUs so you only get the problem 
when it has PVR set to e6500?.

Regards,
BALATON Zoltan