Hi Philippe, On Fri, Dec 13, 2019 at 12:25 AM Philippe Mathieu-Daudé <phi...@redhat.com> wrote:
> Cc'ing Alex. > > On 12/13/19 12:07 AM, Niek Linnenbank wrote: > > Hi Philippe, > > > > I have discovered that the hflags assertion error you reported is not > > caused by the Allwinner H3 > > patches but actually an existing problem. What I did is to use the > > latest master (v4.2.0 tag) without any patches applied. > > and tried to boot the raspi2 machine with and without debugging enabled. > > Without debuggin, the raspi2 > > machine runs fine and can boot the 5.4.2 linux kernel. With debugging > > enabled, the same hflags error shows. > > This might be the same bug I hit last week... Alex suggested a patch: > https://www.mail-archive.com/qemu-devel@nongnu.org/msg664500.html > > Do you mind to try it? > Ahh OK, I was not aware that this was already seen and solved! Sometimes I try use the lists.gnu.org site to keep an eye out for relevant emails going to qemu-devel, but I totally missed this fix. Too many e-mails. Perhaps instead I should just subscribe to the mailing list and use filters. I retried with the raspi2 machine and alex's patch, and indeed the hflags error is gone and the machine starts fine with debugging enabled. Ofcourse, I also retried with the Allwinner H3 patches + alex's fix applied and the orangepi-pc machine, and unfortunately, there the hflags assertion did still show up. Then I looked further to try and understand what is going on, and it looked to me that the hflags is a state variable, that needs to be rebuild after changing some other fields inside the ARM cpu object. And in my patch #0006 I did just that: I tried to resolve the undefined exceptions I got using arm_set_cpu_on(), by setting CP10,CP11 bits. So I tried to use the arm_rebuild_hflags() function after applying the CP10,CP11 bits, and that solved the assertion issue (see below). Can you verify if this change also resolves the hflags assertion on your side? I'll also reply to the mail for patch #0006 with this info. Regards, Niek diff --git a/target/arm/arm-powerctl.c b/target/arm/arm-powerctl.c index f77a950db6..cf2f3d69ab 100644 --- a/target/arm/arm-powerctl.c +++ b/target/arm/arm-powerctl.c @@ -104,6 +104,9 @@ static void arm_set_cpu_on_async_work(CPUState *target_cpu_state, /* Processor is not in secure mode */ target_cpu->env.cp15.scr_el3 |= SCR_NS; + /* Set NSACR.{CP11,CP10} so NS can access the FPU */ + target_cpu->env.cp15.nsacr |= 3 << 10; + /* * If QEMU is providing the equivalent of EL3 firmware, then we need * to make sure a CPU targeting EL2 comes out of reset with a @@ -124,6 +127,9 @@ static void arm_set_cpu_on_async_work(CPUState *target_cpu_state, target_cpu->env.regs[0] = info->context_id; } + /* Ensure hflags is rebuild */ + arm_rebuild_hflags(&target_cpu->env); + /* Start the new CPU at the requested address */ cpu_set_pc(target_cpu_state, info->entry); > > If it still fails, you might also add this one on top: > https://www.mail-archive.com/qemu-devel@nongnu.org/msg663843.html > and report the error. > > That patch is indeed very helpful > > > > To reproduce it, build Linux 5.4.2 with the bmc2835_defconfig: > > > > $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make mrproper > > $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make bcm2835_defconfig > > $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make -j5 > > ... > > > > First build QEMU without debugging and try to boot linux: > > $ ./configure --target-list=arm-softmmu; make clean; make -j5 > > $ ./arm-softmmu/qemu-system-arm -M raspi2 \ > > -kernel $HOME/linux-5.4.2/arch/arm/boot/zImage \ > > -append 'console=ttyAMA0,115200 earlyprintk debug' \ > > -dtb $HOME/linux-5.4.2/arch/arm/boot/dts/bcm2836-rpi-2-b.dtb \ > > -m 1024 -nographic -s > > [ 0.000000] Booting Linux on physical CPU 0x0 > > [ 0.000000] Linux version 5.4.2 (me@host) (gcc version 7.4.0 > (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1)) #1 Thu Dec 12 22:49:14 CET 2019 > > [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), > cr=10c53c7d > > ... > > > > Then rebuild QEMU with debugging enabled and again try to boot linux: > > $ ./configure --target-list=arm-softmmu --enable-debug > --extra-cflags=-ggdb; make clean; make -j5 > > $ ./arm-softmmu/qemu-system-arm -M raspi2 \ > > -kernel $HOME/linux-5.4.2/arch/arm/boot/zImage \ > > -append 'console=ttyAMA0,115200 earlyprintk debug' \ > > -dtb $HOME/linux-5.4.2/arch/arm/boot/dts/bcm2836-rpi-2-b.dtb \ > > -m 1024 -nographic -s > > qemu-system-arm: /home/me/qemu/target/arm/helper.c:11359: > cpu_get_tb_cpu_state: Assertion `flags == rebuild_hflags_internal(env)' > failed. > > qemu-system-arm: /home/me/qemu/target/arm/helper.c:11359: > cpu_get_tb_cpu_state: Assertion `flags == rebuild_hflags_internal(env)' > failed. > > qemu-system-arm: /home/me/qemu/target/arm/helper.c:11359: > cpu_get_tb_cpu_state: Assertion `flags == rebuild_hflags_internal(env)' > failed. > > Aborted (core dumped) > > > > $ git describe > > v4.2.0 > > > > > > What should be the next step? Should this be reported as a bug? > > In this case we might already have the fix, but if Alex patch doesn't > help, you are always welcome to open a bug report: > https://bugs.launchpad.net/qemu/+filebug > This help to have notes/progress gathered. > > > On Tue, Dec 10, 2019 at 9:12 PM Niek Linnenbank > > <nieklinnenb...@gmail.com <mailto:nieklinnenb...@gmail.com>> wrote: > > > > Hi Philippe, > > > > On Tue, Dec 10, 2019 at 9:26 AM Philippe Mathieu-Daudé > > <phi...@redhat.com <mailto:phi...@redhat.com>> wrote: > > > > On 12/9/19 10:37 PM, Niek Linnenbank wrote: > > > Hi Philippe, > > > > > > On Tue, Dec 3, 2019 at 9:47 AM Philippe Mathieu-Daudé > > <phi...@redhat.com <mailto:phi...@redhat.com> > > > <mailto:phi...@redhat.com <mailto:phi...@redhat.com>>> wrote: > > > > > > On 12/2/19 10:09 PM, Niek Linnenbank wrote: > > > > Dear QEMU developers, > > > > > > > > Hereby I would like to contribute the following set of > > patches to > > > QEMU > > > > which add support for the Allwinner H3 System on Chip > > and the > > > > Orange Pi PC machine. The following features and > > devices are > > > supported: > > > > > > > > * SMP (Quad Core Cortex A7) > > > > * Generic Interrupt Controller configuration > > > > * SRAM mappings > > > > * Timer device (re-used from Allwinner A10) > > > > * UART > > > > * SD/MMC storage controller > > > > * EMAC ethernet connectivity > > > > * USB 2.0 interfaces > > > > * Clock Control Unit > > > > * System Control module > > > > * Security Identifier device > > > > > > Awesome! > > > > > > > Functionality related to graphical output such as > > HDMI, GPU, > > > > Display Engine and audio are not included. Recently > > released > > > > mainline Linux kernels (4.19 up to latest master) and > > mainline U-Boot > > > > are known to work. The SD/MMC code is tested using > > bonnie++ and > > > > various tools such as fsck, dd and fdisk. The EMAC is > > verified > > > with iperf3 > > > > using -netdev socket. > > > > > > > > To build a Linux mainline kernel that can be booted by > > the Orange > > > Pi PC > > > > machine, simply configure the kernel using the > > sunxi_defconfig > > > configuration: > > > > $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make > > mrproper > > > > $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make > > sunxi_defconfig > > > > > > > > To be able to use USB storage, you need to manually > > enable the > > > corresponding > > > > configuration item. Start the kconfig configuration > tool: > > > > $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make > > menuconfig > > > > > > > > Navigate to the following item, enable it and save your > > > configuration: > > > > Device Drivers > USB support > USB Mass Storage > support > > > > > > > > Build the Linux kernel with: > > > > $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make -j5 > > > > > > > > To boot the newly build linux kernel in QEMU with the > > Orange Pi > > > PC machine, use: > > > > $ qemu-system-arm -M orangepi -m 512 -nic user > > -nographic \ > > > > -kernel /path/to/linux/arch/arm/boot/zImage \ > > > > -append 'console=ttyS0,115200' \ > > > > -dtb > > /path/to/linux/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dtb > > > > > > > > Note that this kernel does not have a root filesystem. > > You may > > > provide it > > > > with an official Orange Pi PC image [1] either as an > > SD card or as > > > > USB mass storage. To boot using the Orange Pi PC > > Debian image on > > > SD card, > > > > simply add the -sd argument and provide the proper > > root= kernel > > > parameter: > > > > $ qemu-system-arm -M orangepi -m 512 -nic user > > -nographic \ > > > > -kernel /path/to/linux/arch/arm/boot/zImage \ > > > > -append 'console=ttyS0,115200 > root=/dev/mmcblk0p2' \ > > > > -dtb > > > /path/to/linux/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dtb > \ > > > > -sd > > OrangePi_pc_debian_stretch_server_linux5.3.5_v1.0.img > > > > > > > > Alternatively, you can also choose to build and boot a > > recent > > > buildroot [2] > > > > using the orangepi_pc_defconfig or Armbian image [3] > > for Orange > > > Pi PC. > > > > > > Richard, trying the Armbian image from > > > https://apt.armbian.com/pool/main/l/linux-4.20.7-sunxi/ I > get: > > > > > > $ arm-softmmu/qemu-system-arm -M orangepi -m 512 -nic > user \ > > > -append 'console=ttyS0,115200' \ > > > -kernel boot/vmlinuz-4.20.7-sunxi \ > > > -dtb > > usr/lib/linux-image-dev-sunxi/sun8i-h3-orangepi-pc.dtb \ > > > -serial stdio -d unimp > > > Uncompressing Linux... done, booting the kernel. > > > rtc: unimplemented device write (size 4, value > > 0x16aa0001, offset 0x0) > > > rtc: unimplemented device read (size 4, offset 0x0) > > > rtc: unimplemented device read (size 4, offset 0x0) > > > rtc: unimplemented device read (size 4, offset 0x8) > > > qemu-system-arm: target/arm/helper.c:11359: > > cpu_get_tb_cpu_state: > > > Assertion `flags == rebuild_hflags_internal(env)' failed. > > > Aborted (core dumped) > > > > > > > > > I'm trying to reproduce the error you reported here with my > > patch set on > > > latest master, > > > but so far without any result. The host OS I'm using is > > Ubuntu 18.04.3 > > > LTS on x86_64. > > > I ran several times using the same 4.20.7-sunxi kernel and > > same command > > > line. > > > > > > Some questions that might help: > > > 1) Are there any specific steps you did in order to produce > > this error? > > > > I build QEMU with: > > > > ./configure --enable-trace-backends=log --extra-cflags=-ggdb > > --enable-debug > > > > > 2) Could this be a known / existing issue? > > > 3) How many times did you see this error? > > > > Always > > > > > 4) Are you also using Ubuntu 18.04.3 LTS on x86_64, or a > > different host OS? > > > > Host is Fedora 30. > > > > > > OK thanks, I will try again using the info above after I finished > > reworking the other patch comments. > > > > Niek > > -- Niek Linnenbank
