On Sun, 22 Nov 2020 14:34:33 -0800 Vagrant Cascadian <vagr...@debian.org> wrote:
> Thanks for the bug report...
You're welcome!
> Very surprising that extlinux would work but boot.scr would not; they
> almost certainly use the same load addresses...
I was astonished.
> This symptom is sometimes related to the kernel or device tree or
> initramfs overwriting the load address of one of the other values.
BTST :)
> Can you get to a u-boot prompt and:
> printenv fdt_addr_r kernel_addr_r ramdisk_addr_r
=> printenv fdt_addr_r kernel_addr_r ramdisk_addr_r
fdt_addr_r=0x4FA00000
kernel_addr_r=0x40080000
ramdisk_addr_r=0x4FE00000
=>
> Could you downgrade to the 2020.10+dfsg-1 version from
> snapshot.debian.org and see if that has the same issue?
Done.
extlinux: booting
boot.scr: failed
---8<---
U-Boot SPL 2020.10+dfsg-1 (Oct 05 2020 - 19:13:28 +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 0x4093960, 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 (Oct 05 2020 - 19:13:28 +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
2417 bytes read in 1 ms (2.3 MiB/s)
## Executing script at 4fc00000
bootargs:
bootargs=console=ttyS0,115200 quiet
fk_kvers:
fk_kvers=5.9.0-2-arm64
fdtpath:
fdtpath=dtbs/5.9.0-2-arm64/allwinner/sun50i-a64-olinuxino-emmc.dtb
partition:
partition=1
addr:
fdt_addr_r=0x4FA00000
kernel_addr_r=0x40080000
ramdisk_addr_r=0x4FE00000
22744944 bytes read in 1004 ms (21.6 MiB/s)
28403 bytes read in 4 ms (6.8 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 ...
---8<---
>
> > I got into the same situation during an update on an other system to
> > bullseye.
>
> What other board?
Also an Olimex A64-Olinuxino-eMMC. Did an update from a running
Debian-Image provided by Olimex.
Therefore the Problem exists on:
1) Olimex A64-Olinuxino-eMMC
Fresh Debian Install (bullseye) as described above.
2) Olimex A64-Olinuxino-eMMC
Update to bullseye from a Debian-Image provided by Olimex.
> > 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?
I can try to get earlyprintk running.
> Maybe add some debugging into the boot.scr used in /etc/flash-kernel/
OK. Will do.
> I'll test on a few of my systems to see if I can reproduce the issue.
OK.
Thx
Bene
pgpMqB2u76p_J.pgp
Description: Digitale Signatur von OpenPGP
