Control: version 975490 2020.10+dfsg-1+b1 Thanks for the bug report...
On 2020-11-22, Benedikt Spranger wrote: > after a fresh install of Debian "bullseye" the first reboot got stuck > after "Starting kernel ..." > > It turend out that booting the system got always stuck using the a > "normal" u-boot boot sequence. Using extlinux or FIT-Images is not > affected. > > boot.scr : FAIL > extlinux : OK > FIT-Image: OK > > Since the Debian Installer provides neither extlinux configuration nor > build a FIT-Image the system is unusable after the reboot from the > installer. Very surprising that extlinux would work but boot.scr would not; they almost certainly use the same load addresses... This symptom is sometimes related to the kernel or device tree or initramfs overwriting the load address of one of the other values. Can you get to a u-boot prompt and: printenv fdt_addr_r kernel_addr_r ramdisk_addr_r Could you downgrade to the 2020.10+dfsg-1 version from snapshot.debian.org and see if that has the same issue? > I got into the same situation during an update on an other system to > bullseye. What other board? > Bootlog: > ---8<--- > U-Boot SPL 2020.10+dfsg-1+b1 (Nov 19 2020 - 03:18:11 +0000) > DRAM: 1024 MiB > Trying to boot from MMC2 > NOTICE: BL31: v2.3(): > NOTICE: BL31: Built : 05:17:48, Oct 18 2020 > NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689) > NOTICE: BL31: Found U-Boot DTB at 0x4093968, model: Olimex > A64-Olinuxino-eMMC INFO: ARM GICv2 driver initialized > INFO: Configuring SPC Controller > INFO: PMIC: Probing AXP803 on RSB > INFO: PMIC: Enabling DRIVEVBUS > INFO: PMIC: dcdc1 voltage: 3.300V > INFO: PMIC: dcdc5 voltage: 1.360V > INFO: PMIC: dcdc6 voltage: 1.100V > INFO: PMIC: dldo1 voltage: 3.300V > INFO: PMIC: dldo2 voltage: 3.300V > INFO: PMIC: dldo3 voltage: 2.800V > INFO: PMIC: dldo4 voltage: 3.300V > INFO: PMIC: fldo1 voltage: 1.200V > INFO: PMIC: Enabling DC SW > INFO: BL31: Platform setup done > INFO: BL31: Initializing runtime services > INFO: BL31: cortex_a53: CPU workaround for 843419 was applied > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied > NOTICE: PSCI: System suspend is unavailable > INFO: BL31: Preparing for EL3 exit to normal world > INFO: Entry point address = 0x4a000000 > INFO: SPSR = 0x3c9 > alloc space exhausted > > > U-Boot 2020.10+dfsg-1+b1 (Nov 19 2020 - 03:18:11 +0000) Allwinner > Technology > > CPU: Allwinner A64 (SUN50I) > Model: Olimex A64-Olinuxino-eMMC > DRAM: 1 GiB > MMC: mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1 > Loading Environment from FAT... Unable to use mmc 1:1... In: serial > Out: serial > Err: serial > Net: phy interface7 > eth0: ethernet@1c30000 > starting USB... > Bus usb@1c1a000: USB EHCI 1.00 > Bus usb@1c1a400: USB OHCI 1.0 > Bus usb@1c1b000: USB EHCI 1.00 > Bus usb@1c1b400: USB OHCI 1.0 > scanning bus usb@1c1a000 for devices... 1 USB Device(s) found > scanning bus usb@1c1a400 for devices... 1 USB Device(s) found > scanning bus usb@1c1b000 for devices... 1 USB Device(s) found > scanning bus usb@1c1b400 for devices... 1 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc1(part 0) is current device > Scanning mmc 1:1... > Found U-Boot script /boot.scr > 2225 bytes read in 2 ms (1.1 MiB/s) > ## Executing script at 4fc00000 > 22744944 bytes read in 1003 ms (21.6 MiB/s) > 28403 bytes read in 5 ms (5.4 MiB/s) > 30071341 bytes read in 1326 ms (21.6 MiB/s) > Booting Debian 5.9.0-2-arm64 from mmc 1:1... > Moving Image from 0x40080000 to 0x40200000, end=41850000 > ## Flattened Device Tree blob at 4fa00000 > Booting using the fdt blob at 0x4fa00000 > EHCI failed to shut down host controller. > Loading Ramdisk to 48352000, end 49fffa2d ... OK > Loading Device Tree to 0000000048348000, end 0000000048351ef2 ... OK > > Starting kernel ... I wish flash-kernel were more verbose about which files it is loading... are there other similar variants to this board that require a different device-tree and is the boot.scr loading the correct one? Maybe add some debugging into the boot.scr used in /etc/flash-kernel/ I'll test on a few of my systems to see if I can reproduce the issue. live well, vagrant
signature.asc
Description: PGP signature
