Cannot boot arm kernel images on s390x
While running the acceptance tests on s390x, the arm tests under qemu/tests/acceptance/boot_linux_console.py will timeout, except the test using u-boot. All the arm tests run without problems on x86 and ppc. This test boots the kernel and wait for a kernel panic to make sure it can boot that kind of kernel on the host running the test. The URL for the kernels are available inside the python test code, but I'm listing them here: Fail: https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/29/Everything/armhfp/os/images/pxeboot/vmlinuz Fail: http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi- firmware/raspberrypi-kernel_1.20190215-1_armhf.deb Fail: https://snapshot.debian.org/archive/debian/20190928T224601Z/pool/main/l/linux/linux- image-4.19.0-6-armmp_4.19.67-2+deb10u1_armhf.deb Pass: https://raw.githubusercontent.com/Subbaraya-Sundeep/qemu-test- binaries/fa030bd77a014a0b8e360d3b7011df89283a2f0b/spi.bin I tried to manually investigate the problem with the first kernel of the list. The command I used to try to boot it was: /home/linux1/src/v4.2.0-rc3/bin/qemu-system-arm -serial stdio -machine virt -kernel /home/linux1/venv/python3/data/cache/by_location/1d5fdf8018e79b806aa982600c0866b199946efc/vmlinuz -append "printk.time=0 console=ttyAMA0" On an x86 machine, I can see it boots and ends with a kernel panic as expected. On s390x, it just hangs. I also tried to debug with gdb, redirecting the monitor and the serial console to other terminal sessions without success. QEMU version is the latest as of today,tag v4.2.0-rc4, commit 1bdc319ab5d289ce6b822e06fb2b13666fd9278e. s390x system is a Red Hat Enterprise Linux Server 7.7 running as a z/VM 6.4.0 guest at IBM LinuxONE Community Cloud. x86 system is a Fedora 31 running on Intel i7-8650U.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information