Bug#1028343: u-boot-qemu 2023.01~rc4+dfsg-2: riscv64: FDT creation failed
Control: tags 1028343 pending On 2023-01-11, Karsten Merker wrote: > On Wed, Jan 11, 2023 at 09:21:42AM -0800 Vagrant Cascadian wrote: >> Definitely would be good to mention to upstream. Please Cc me if you do! > > I've sent the bugreport upstream: > https://lists.denx.de/pipermail/u-boot/2023-January/504466.html Thanks, that worked well! A patch was submitted upstream, and I've tested and committed the patch to the packaging for Debian, so should be included in the next upload: https://salsa.debian.org/debian/u-boot/-/commit/8ebfba031bc7dad7594669ed00eb8a17c6ed3808 https://salsa.debian.org/debian/u-boot/-/commit/f2aad8950a124f011c926445361b90efe76c8dd2 live well, vagrant signature.asc Description: PGP signature
Bug#1028343: u-boot-qemu 2023.01~rc4+dfsg-2: riscv64: FDT creation failed
Control: tags -1 upstream X-Debbugs-CC: debian-ri...@lists.debian.org On Wed, Jan 11, 2023 at 09:21:42AM -0800 Vagrant Cascadian wrote: > Definitely would be good to mention to upstream. Please Cc me if you do! I've sent the bugreport upstream: https://lists.denx.de/pipermail/u-boot/2023-January/504466.html Regards, Karsten -- Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Bug#1028343: u-boot-qemu 2023.01~rc4+dfsg-2: riscv64: FDT creation failed
On 2023-01-11, Karsten Merker wrote: > On Tue, Jan 10, 2023 at 09:22:02PM +0100 Karsten Merker wrote: > >> I've also taken a look at the u-boot changelogs and there have >> been quite a few changes concerning u-boot's handling of >> device-trees between the working and the non-working versions. >> Unfortunately I'm not familiar enough with the inner workings of >> u-boot to understand the implications of several of these >> changes. > > Hello, > > I've tried narrowing down the source of the issue by using > git bisect on the u-boot tree and that has resulted in > the following commit as the potential culprit: > > commit a56f663f07073713042bb0fd08053aeb667e717b > Author: Simon Glass > Date: Thu Oct 20 18:23:14 2022 -0600 > > vbe: Add info about the VBE device to the fwupd node > > At present we put the driver in the /chosen node in U-Boot. This is a bit > strange, since U-Boot doesn't normally use that node itself. It is better > to put it under the bootstd node. > > To make this work we need to copy create the node under /chosen when > fixing up the device tree. Copy over all the properties so that fwupd > knows what to do. > > Update the sandbox device tree accordingly. > > Signed-off-by: Simon Glass Thanks for digging into this! > I'm not sure whether this is the actual culprit or just an > operation that happens to expose a problem elsewhere, though. > I'm inclined to forward the bug report to u-boot upstream unless > somebody has another idea how to get this narrowed down further. Reverting just that commit seems doable (one smallish conflict) to test with greater confidence, though as you say, it could just be revealing other bugs. I do not see any debian-specific patches that are likely to be relevent. If it is annoyingly subtle, it might also be the intersection of ... particular qemu, opensbi and u-boot versions... Definitely would be good to mention to upstream. Please Cc me if you do! If you would rather I nudge this upstream, let me know. live well, vagrant
Bug#1028343: u-boot-qemu 2023.01~rc4+dfsg-2: riscv64: FDT creation failed
X-Debbugs-CC: debian-ri...@lists.debian.org On Tue, Jan 10, 2023 at 09:22:02PM +0100 Karsten Merker wrote: > I've also taken a look at the u-boot changelogs and there have > been quite a few changes concerning u-boot's handling of > device-trees between the working and the non-working versions. > Unfortunately I'm not familiar enough with the inner workings of > u-boot to understand the implications of several of these > changes. Hello, I've tried narrowing down the source of the issue by using git bisect on the u-boot tree and that has resulted in the following commit as the potential culprit: commit a56f663f07073713042bb0fd08053aeb667e717b Author: Simon Glass Date: Thu Oct 20 18:23:14 2022 -0600 vbe: Add info about the VBE device to the fwupd node At present we put the driver in the /chosen node in U-Boot. This is a bit strange, since U-Boot doesn't normally use that node itself. It is better to put it under the bootstd node. To make this work we need to copy create the node under /chosen when fixing up the device tree. Copy over all the properties so that fwupd knows what to do. Update the sandbox device tree accordingly. Signed-off-by: Simon Glass I'm not sure whether this is the actual culprit or just an operation that happens to expose a problem elsewhere, though. I'm inclined to forward the bug report to u-boot upstream unless somebody has another idea how to get this narrowed down further. Regards, Karsten -- Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Bug#1028343: u-boot-qemu 2023.01~rc4+dfsg-2: riscv64: FDT creation failed
Control: found -1 2023.01+dfsg-1 X-Debbugs-CC: debian-ri...@lists.debian.org On Tue, Jan 10, 2023 at 09:23:04AM -0800 Vagrant Cascadian wrote: > On 2023-01-10, Cheng Li wrote: [...] > > Moving Image from 0x8400 to 0x8020, end=815d8000 > > ## Flattened Device Tree blob at ff733ef0 > > Booting using the fdt blob at 0xff733ef0 > > Working FDT set to ff733ef0 > > Using Device Tree in place at ff733ef0, end ff738dd2 > > Working FDT set to ff733ef0 > > ERROR: fdt fixup event failed: -22 > > - must RESET the board to recover. > > > > FDT creation failed! hanging...### ERROR ### Please RESET the board ### > > I wonder if this is relevent? > > docs/firmware: Update FW_JUMP documentation > > https://github.com/riscv-software-src/opensbi/commit/7105c189f67028ef73720d7e9816c800ab53dda5 > > Basically changing the address offsets to avoid clobbering one another... Hello, some clobbering could indeed be the source of the problem, though I currently fail to see why that would happen. When running the objdump dance on the working u-boot 2022.10, this gives me the following address blocks: 0x802001a4 0x80200e60 0x80259bbc 0x80275a38 0x802769d1 0x802770c8 0x802778b8 0x80283d60 0x80283e70 0x80284628 0x80287f88 0x80288138 0x8029c2b0 0x8029d9a8 0x802a8008 On the non-working u-boot 2023.01 that is in unstable since today this gives me 0x802001a4 0x80200e70 0x8025a604 0x802762f4 0x802772e8 0x802779ec 0x802781f4 0x802847a8 0x802848b8 0x80285098 0x80288a08 0x80288bb8 0x8029cf40 0x8029e6b0 0x802a8d08 i.e. the used area is a little bit larger in the non-working case, but still way below one MB. On the other hand OpenSBI's ./platform/generic/config.mk contains FW_JUMP_FDT_ADDR=$(shell printf "0x%X" $$(($(FW_TEXT_START) + 0x220))) i.e. AIUI it reserves an area of 0x220 bytes (34MB) for it's payload, so there should be plenty of space and no clobbering should occur. I've also taken a look at the u-boot changelogs and there have been quite a few changes concerning u-boot's handling of device-trees between the working and the non-working versions. Unfortunately I'm not familiar enough with the inner workings of u-boot to understand the implications of several of these changes. Regards, Karsten -- Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Bug#1028343: u-boot-qemu 2023.01~rc4+dfsg-2: riscv64: FDT creation failed
On 2023-01-10, Cheng Li wrote: > qemu-system-riscv64 \ > -nographic \ > -machine virt \ > -smp 8 -m 8G \ > -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf \ > -kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf \ > -object rng-random,filename=/dev/urandom,id=rng0 \ > -device virtio-rng-device,rng=rng0 \ > -append "console=ttyS0 rw root=/dev/vda1" \ > -device virtio-blk-device,drive=hd0 -drive > file=rootfs.img,format=raw,id=hd0 \ > -device virtio-net-device,netdev=usernet -netdev > user,id=usernet,hostfwd=tcp::22 > > *" -kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf "* > > shiptux@Debian:~/riscv64/vm/riscv-deb$ dpkg-deb -c > u-boot-qemu_2023.01~rc4+dfsg-2_all.deb | grep uboot.elf > -rw-r--r-- root/root 357888 2023-01-06 11:38 > ./usr/lib/u-boot/malta64el/uboot.elf > -rw-r--r-- root/root 312692 2023-01-06 11:38 > ./usr/lib/u-boot/maltael/uboot.elf > -rw-r--r-- root/root 449032 2023-01-06 11:38 > ./usr/lib/u-boot/qemu-ppce500/uboot.elf > -rw-r--r-- root/root 652176 2023-01-06 11:38 > ./usr/lib/u-boot/qemu-riscv64/uboot.elf > *-rw-r--r-- root/root 653928 2023-01-06 11:38 > ./usr/lib/u-boot/qemu-riscv64_smode/uboot.elf* > > Enter choice: 1 > 1: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 > Retrieving file: /boot/initrd.img-6.0.0-5-riscv64 > Retrieving file: /boot/vmlinux-6.0.0-5-riscv64 > append: rw noquiet root=/dev/vda1 > Moving Image from 0x8400 to 0x8020, end=815d8000 > ## Flattened Device Tree blob at ff733ef0 > Booting using the fdt blob at 0xff733ef0 > Working FDT set to ff733ef0 > Using Device Tree in place at ff733ef0, end ff738dd2 > Working FDT set to ff733ef0 > ERROR: fdt fixup event failed: -22 > - must RESET the board to recover. > > FDT creation failed! hanging...### ERROR ### Please RESET the board ### I wonder if this is relevent? docs/firmware: Update FW_JUMP documentation https://github.com/riscv-software-src/opensbi/commit/7105c189f67028ef73720d7e9816c800ab53dda5 Basically changing the address offsets to avoid clobbering one another... live well, vagrant signature.asc Description: PGP signature
Bug#1028343: u-boot-qemu 2023.01~rc4+dfsg-2: riscv64: FDT creation failed
Hello, I have the same issue with Karsten: Here is my command line: qemu-system-riscv64 \ -nographic \ -machine virt \ -smp 8 -m 8G \ -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf \ -kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf \ -object rng-random,filename=/dev/urandom,id=rng0 \ -device virtio-rng-device,rng=rng0 \ -append "console=ttyS0 rw root=/dev/vda1" \ -device virtio-blk-device,drive=hd0 -drive file=rootfs.img,format=raw,id=hd0 \ -device virtio-net-device,netdev=usernet -netdev user,id=usernet,hostfwd=tcp::22 *" -kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf "* shiptux@Debian:~/riscv64/vm/riscv-deb$ dpkg-deb -c u-boot-qemu_2023.01~rc4+dfsg-2_all.deb | grep uboot.elf -rw-r--r-- root/root 357888 2023-01-06 11:38 ./usr/lib/u-boot/malta64el/uboot.elf -rw-r--r-- root/root 312692 2023-01-06 11:38 ./usr/lib/u-boot/maltael/uboot.elf -rw-r--r-- root/root 449032 2023-01-06 11:38 ./usr/lib/u-boot/qemu-ppce500/uboot.elf -rw-r--r-- root/root 652176 2023-01-06 11:38 ./usr/lib/u-boot/qemu-riscv64/uboot.elf *-rw-r--r-- root/root 653928 2023-01-06 11:38 ./usr/lib/u-boot/qemu-riscv64_smode/uboot.elf* Enter choice: 1 1: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 Retrieving file: /boot/initrd.img-6.0.0-5-riscv64 Retrieving file: /boot/vmlinux-6.0.0-5-riscv64 append: rw noquiet root=/dev/vda1 Moving Image from 0x8400 to 0x8020, end=815d8000 ## Flattened Device Tree blob at ff733ef0 Booting using the fdt blob at 0xff733ef0 Working FDT set to ff733ef0 Using Device Tree in place at ff733ef0, end ff738dd2 Working FDT set to ff733ef0 ERROR: fdt fixup event failed: -22 - must RESET the board to recover. FDT creation failed! hanging...### ERROR ### Please RESET the board ### Works fine in u-boot-qemu 2022.10+dfsg-2 Version with same command line: Retrieving file: /boot/vmlinux-6.0.0-5-riscv64 append: rw noquiet root=/dev/vda1 Moving Image from 0x8400 to 0x8020, end=815d8000 ## Flattened Device Tree blob at ff733ef0 Booting using the fdt blob at 0xff733ef0 Using Device Tree in place at ff733ef0, end ff738dd2 On 2023/1/10 02:17, Karsten Merker wrote: Source: u-boot Version: 2023.01~rc4+dfsg-2 Severity: important User:debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-CC:debian-ri...@lists.debian.org Hello, when booting a riscv64 VM in qemu 1:7.0+dfsg-1 with OpenSBI 1.1-2 and u-boot-qemu 2023.01~rc4+dfsg-2 with the following commandline qemu-system-riscv64 -smp 4 -nographic -machine virt -m 8G -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/u-boot.bin -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -append "console=ttyS0 rw root=/dev/vda1 scsi_mod.use_blk_mq=0" -device virtio-blk-device,drive=hd0 -drive file=riscv64.img,format=raw,id=hd0 -device virtio-net-device,netdev=usernet -netdev user,id=usernet,hostfwd=tcp::2-:22 the following error occurs: -8<--8<--8<--8<--8<- OpenSBI v1.1 _ _ / __ \ / | _ \_ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ \___ \| _ < | | | |__| | |_) | __/ | | |) | |_) || |_ \/| .__/ \___|_| |_|_/|/_| | | |_| Platform Name : riscv-virtio,qemu Platform Features : medeleg Platform HART Count : 4 Platform IPI Device : aclint-mswi Platform Timer Device : aclint-mtimer @ 1000Hz Platform Console Device : uart8250 Platform HSM Device : --- Platform Reboot Device: sifive_test Platform Shutdown Device : sifive_test Firmware Base : 0x8000 Firmware Size : 312 KB Runtime SBI Version : 1.0 Domain0 Name : root Domain0 Boot HART : 2 Domain0 HARTs : 0*,1*,2*,3* Domain0 Region00 : 0x0200-0x0200 (I) Domain0 Region01 : 0x8000-0x8007 () Domain0 Region02 : 0x-0x (R,W,X) Domain0 Next Address : 0x8020 Domain0 Next Arg1 : 0x8220 Domain0 Next Mode : S-mode Domain0 SysReset : yes Boot HART ID : 2 Boot HART Domain : root Boot HART Priv Version: v1.12 Boot HART Base ISA: rv64imafdch Boot HART ISA Extensions : time,sstc Boot HART PMP Count : 16 Boot HART PMP Granularity : 4 Boot HART PMP Address Bits: 54 Boot HART MHPM Count : 16 Boot HART MIDELEG : 0x1666 Boot HART MEDELEG : 0x00f0b509 U-Boot 2023.01-rc4+dfsg-2 (Jan 06 2023 - 03:38:24 +) CPU: rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc Model: riscv-virtio,qemu DRAM: 8 GiB Core: 31 devices, 15 uclasses, devicetree: board Flash: 32 MiB Loading Environment from
Bug#1028343: u-boot-qemu 2023.01~rc4+dfsg-2: riscv64: FDT creation failed
Source: u-boot Version: 2023.01~rc4+dfsg-2 Severity: important User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-CC: debian-ri...@lists.debian.org Hello, when booting a riscv64 VM in qemu 1:7.0+dfsg-1 with OpenSBI 1.1-2 and u-boot-qemu 2023.01~rc4+dfsg-2 with the following commandline qemu-system-riscv64 -smp 4 -nographic -machine virt -m 8G -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/u-boot.bin -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -append "console=ttyS0 rw root=/dev/vda1 scsi_mod.use_blk_mq=0" -device virtio-blk-device,drive=hd0 -drive file=riscv64.img,format=raw,id=hd0 -device virtio-net-device,netdev=usernet -netdev user,id=usernet,hostfwd=tcp::2-:22 the following error occurs: -8<--8<--8<--8<--8<- OpenSBI v1.1 _ _ / __ \ / | _ \_ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ \___ \| _ < | | | |__| | |_) | __/ | | |) | |_) || |_ \/| .__/ \___|_| |_|_/|/_| | | |_| Platform Name : riscv-virtio,qemu Platform Features : medeleg Platform HART Count : 4 Platform IPI Device : aclint-mswi Platform Timer Device : aclint-mtimer @ 1000Hz Platform Console Device : uart8250 Platform HSM Device : --- Platform Reboot Device: sifive_test Platform Shutdown Device : sifive_test Firmware Base : 0x8000 Firmware Size : 312 KB Runtime SBI Version : 1.0 Domain0 Name : root Domain0 Boot HART : 2 Domain0 HARTs : 0*,1*,2*,3* Domain0 Region00 : 0x0200-0x0200 (I) Domain0 Region01 : 0x8000-0x8007 () Domain0 Region02 : 0x-0x (R,W,X) Domain0 Next Address : 0x8020 Domain0 Next Arg1 : 0x8220 Domain0 Next Mode : S-mode Domain0 SysReset : yes Boot HART ID : 2 Boot HART Domain : root Boot HART Priv Version: v1.12 Boot HART Base ISA: rv64imafdch Boot HART ISA Extensions : time,sstc Boot HART PMP Count : 16 Boot HART PMP Granularity : 4 Boot HART PMP Address Bits: 54 Boot HART MHPM Count : 16 Boot HART MIDELEG : 0x1666 Boot HART MEDELEG : 0x00f0b509 U-Boot 2023.01-rc4+dfsg-2 (Jan 06 2023 - 03:38:24 +) CPU: rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc Model: riscv-virtio,qemu DRAM: 8 GiB Core: 31 devices, 15 uclasses, devicetree: board Flash: 32 MiB Loading Environment from nowhere... OK In:serial@1000 Out: serial@1000 Err: serial@1000 Net: eth0: virtio-net#2 Working FDT set to ff7344b0 Hit any key to stop autoboot: 0 Device 0: QEMU VirtIO Block Device Type: Hard Disk Capacity: 102400.0 MB = 100.0 GB (209715200 x 512) ... is now current device Scanning virtio 0:1... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf U-Boot menu 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 2: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target) 3: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 4: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target) 5: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 6: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target) Enter choice: 1:Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 Retrieving file: /boot/initrd.img-6.1.0-1-riscv64 Retrieving file: /boot/vmlinux-6.1.0-1-riscv64 append: root=/dev/vda1 rw noquiet Moving Image from 0x8400 to 0x8020, end=815e5000 ## Flattened Device Tree blob at ff7344b0 Booting using the fdt blob at 0xff7344b0 Working FDT set to ff7344b0 Using Device Tree in place at ff7344b0, end ff738dea Working FDT set to ff7344b0 ERROR: fdt fixup event failed: -22 - must RESET the board to recover. FDT creation failed! hanging...### ERROR ### Please RESET the board ### -8<--8<--8<--8<--8<- The source of the issue seems to be in u-boot as with u-boot-qemu 2022.10+dfsg-2 (the previous u-boot release in Debian/sid) everything works without problems (boot log below). The problem appears to be independent from the kernel image that gets booted - all three installed kernels boot fine with u-boot-qemu 2022.10+dfsg-2 but trying to boot any of them with u-boot-qemu 2023.01~rc4+dfsg-2 shows the above error. I've also tested the previous u-boot 2023.01 release candidates from experimental (2023.01-rc2+dfsg-1 and 2023.01-rc3+dfsg-1) and they show the same behaviour as 2023.01~rc4+dfsg-2. For comparison, a working boot process with u-boot-qemu 2022.10+dfsg-2:
