Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."
This is from the cloned bug but belongs here.
Am 18.05.21 um 08:31 schrieb Heinrich Schuchardt:
The original problem report showed the following situation was hit:
common/malloc_simple.c:29:
log_err("alloc space exhausted\n");
You cannot expect normal system behavior when reaching this situation.
The available space for simple malloc is defined by:
CONFIG_SPL_SYS_MALLOC_F_LEN=0x2000
CONFIG_SYS_MALLOC_F_LEN=0x2000
I assume that the problem arises in main U-Boot not in SPL. Please,
increase CONFIG_SYS_MALLOC_F_LEN and check if this error message goes away.
Best regards
Heinrich
Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."
Control: clone 975490 -1 Control: retitle -1 bootefi causes boot failure with boot.scr Control: tags -1 + fixed-upstream Control: tags -1 + patch Control: severity -1 important On 2021-04-16, Bastian Germann wrote: > On a Lamobo R1, I can verify 2021.01 versions not to boot with a > default environment. However, 2020.10+dfsg-2 boots. Even though the > original issue has the same outcome, I guess it is caused by something > else. Different enough to warrant it's own bug, cloning... > I figured out my problem is caused by > https://github.com/u-boot/u-boot/commit/f3866909e35074ea6f50226d40487a180de1132f. > The > boot_efi_bootmgr will run and read a bad dtb, which makes a boot.scr > boot fail. This would definitely be good to fix in bullseye, but this is quite late in the release cycle. Will need to test failure and success cases with and without EFI as well as boot.scr and extlinux.conf to make sure this doesn't cause regressions in other boot paths... An ugly workaround in the meantime would be to add a no-op boot.scr on the media (e.g. mmc0) and then fall back to the other boot methods. live well, vagrant signature.asc Description: PGP signature
Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."
On Fri, 16 Apr 2021 17:06:37 +0200 Bastian Germann wrote: > The issue is fixed in 2021.04 (experimental) which has the same default environment as 2021.01. The upstream commit that fixed this is https://github.com/u-boot/u-boot/commit/82d01f04facef1276cede067efd02d2a731ffe83 It applies cleanly on 2021.01+dfsg-4. Please include it or change the config for the affected boards not to try EFI bootmanager. Any news on this? It would be great if that patch would be integrated into the bullseye version.
Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."
Am 16.04.21 um 14:25 schrieb Bastian Germann: The issue is fixed in 2021.04 (experimental) which has the same default environment as 2021.01. The upstream commit that fixed this is https://github.com/u-boot/u-boot/commit/82d01f04facef1276cede067efd02d2a731ffe83 It applies cleanly on 2021.01+dfsg-4. Please include it or change the config for the affected boards not to try EFI bootmanager.
Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."
On 2021-04-16, Bastian Germann wrote: > On Wed, 10 Feb 2021 09:37:01 +0100 Ivo De Decker wrote: >> > With a locally built version of 2020.10+dfsg-2, I can no longer >> > reproduce this issue at all. >> > >> > Could you try with the new version? >> >> Testing/unstable now has version 2021.01+dfsg-2. Benedikt, could you try this >> version to see if the issue is still there? > > On a Lamobo R1, I can verify 2021.01 versions not to boot with a default > environment. However, > 2020.10+dfsg-2 boots. Even though the original issue has the same outcome, I > guess it is caused by > something else. I figured out my problem is caused by > https://github.com/u-boot/u-boot/commit/f3866909e35074ea6f50226d40487a180de1132f. > The > boot_efi_bootmgr will run and read a bad dtb, which makes a boot.scr boot > fail. > > The issue is fixed in 2021.04 (experimental) which has the same default > environment as 2021.01. I can confirm this on the Lamobo R1, when rootfs is on scsi0 and it first attempts to boot from microSD (failing to find boot_efi on mmc0). If I force it to boot from scsi0 first by interrupting the boot to get to a u-boot shell, and typing "setenv boot_targets scsi0", it worked fine with 2021.01 (e.g. it didn't hit the bootefi codepath) as well. Booting the debian-installer image from https://d-i.debian.org/daily-images/armhf/20210416-00:15/netboot/SD-card-images/ worked for me (which currently uses 2021.01). That said, I'm not sure if this is the same issue as in the original report, as the symptom stuck at "Starting kernel ..." can be caused by a wide variety of issues... live well, vagrant signature.asc Description: PGP signature
Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."
On Wed, 10 Feb 2021 09:37:01 +0100 Ivo De Decker wrote: On Mon, Jan 04, 2021 at 08:27:51PM -0800, Vagrant Cascadian wrote: > >> I'll test on a few of my systems to see if I can reproduce the issue. > > > > I can confirm similar behavior on a pinebook, although the kernel does > > boot and actually load, and eventually displays on the LCD display (if I > > "setenv console" from u-boot commandline). It even responds > > appropriately to ctrl-alt-delete, so it is not a completely hung > > kernel... > > With a locally built version of 2020.10+dfsg-2, I can no longer > reproduce this issue at all. > > Could you try with the new version? Testing/unstable now has version 2021.01+dfsg-2. Benedikt, could you try this version to see if the issue is still there? On a Lamobo R1, I can verify 2021.01 versions not to boot with a default environment. However, 2020.10+dfsg-2 boots. Even though the original issue has the same outcome, I guess it is caused by something else. I figured out my problem is caused by https://github.com/u-boot/u-boot/commit/f3866909e35074ea6f50226d40487a180de1132f. The boot_efi_bootmgr will run and read a bad dtb, which makes a boot.scr boot fail. The issue is fixed in 2021.04 (experimental) which has the same default environment as 2021.01.
Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."
Hi, On Mon, Jan 04, 2021 at 08:27:51PM -0800, Vagrant Cascadian wrote: > >> I'll test on a few of my systems to see if I can reproduce the issue. > > > > I can confirm similar behavior on a pinebook, although the kernel does > > boot and actually load, and eventually displays on the LCD display (if I > > "setenv console" from u-boot commandline). It even responds > > appropriately to ctrl-alt-delete, so it is not a completely hung > > kernel... > > With a locally built version of 2020.10+dfsg-2, I can no longer > reproduce this issue at all. > > Could you try with the new version? Testing/unstable now has version 2021.01+dfsg-2. Benedikt, could you try this version to see if the issue is still there? Thanks, Ivo
Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."
On 2020-11-27, Vagrant Cascadian wrote: > On 2020-11-22, Vagrant Cascadian wrote: >> On 2020-11-22, Benedikt Spranger wrote: >>> after a fresh install of Debian "bullseye" the first reboot got stuck >>> after "Starting kernel ..." > ... >>> U-Boot 2020.10+dfsg-1+b1 (Nov 19 2020 - 03:18:11 +) Allwinner >>> Technology > ... >>> Scanning mmc 1:1... >>> Found U-Boot script /boot.scr >>> 2225 bytes read in 2 ms (1.1 MiB/s) >>> ## Executing script at 4fc0 >>> 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 0x4008 to 0x4020, end=4185 >>> ## Flattened Device Tree blob at 4fa0 >>>Booting using the fdt blob at 0x4fa0 >>> EHCI failed to shut down host controller. >>>Loading Ramdisk to 48352000, end 49fffa2d ... OK >>>Loading Device Tree to 48348000, end 48351ef2 ... OK >>> >>> Starting kernel ... > ... >> I'll test on a few of my systems to see if I can reproduce the issue. > > I can confirm similar behavior on a pinebook, although the kernel does > boot and actually load, and eventually displays on the LCD display (if I > "setenv console" from u-boot commandline). It even responds > appropriately to ctrl-alt-delete, so it is not a completely hung > kernel... With a locally built version of 2020.10+dfsg-2, I can no longer reproduce this issue at all. Could you try with the new version? live well, vagrant signature.asc Description: PGP signature
Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."
On Fri, 27 Nov 2020 18:34:13 -0800 Vagrant Cascadian wrote: > On 2020-11-23, Benedikt Spranger wrote: > > On Sun, 22 Nov 2020 14:34:33 -0800 > > Vagrant Cascadian wrote: > > > U-Boot 2020.10+dfsg-1 (Oct 05 2020 - 19:13:28 +) Allwinner > > Technology > ... > > Found U-Boot script /boot.scr > > 2417 bytes read in 1 ms (2.3 MiB/s) > > ## Executing script at 4fc0 > > bootargs: > > bootargs=console=ttyS0,115200 quiet > > Just to be clear, you're using the serial console at ttyS0 at 115200 > baud? Yes, I am using the serial console. > Or are you expecting HDMI output or some other console output? I am old fashioned serial console guy and I am happy not to get stuck on 9600 ;) > If you're not expecting to be using the serial console, the problem > may be: > https://bugs.debian.org/969070 No HDMI here - please notice, if I should check. I am expecting output on a serial console. Regards Bene pgpjrzsO8TJxl.pgp Description: Digitale Signatur von OpenPGP
Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."
On 2020-11-22, Vagrant Cascadian wrote: > On 2020-11-22, Benedikt Spranger wrote: >> after a fresh install of Debian "bullseye" the first reboot got stuck >> after "Starting kernel ..." ... >> U-Boot 2020.10+dfsg-1+b1 (Nov 19 2020 - 03:18:11 +) Allwinner >> Technology ... >> Scanning mmc 1:1... >> Found U-Boot script /boot.scr >> 2225 bytes read in 2 ms (1.1 MiB/s) >> ## Executing script at 4fc0 >> 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 0x4008 to 0x4020, end=4185 >> ## Flattened Device Tree blob at 4fa0 >>Booting using the fdt blob at 0x4fa0 >> EHCI failed to shut down host controller. >>Loading Ramdisk to 48352000, end 49fffa2d ... OK >>Loading Device Tree to 48348000, end 48351ef2 ... OK >> >> Starting kernel ... ... > I'll test on a few of my systems to see if I can reproduce the issue. I can confirm similar behavior on a pinebook, although the kernel does boot and actually load, and eventually displays on the LCD display (if I "setenv console" from u-boot commandline). It even responds appropriately to ctrl-alt-delete, so it is not a completely hung kernel... It definitely gets as far as the initrd for me, as setting break=top in the boot arguments stalls out with a blank screen, and setting break=premount it actually manages to load the LCD and keyboard drivers ... and then stalls out before giving me a shell where it would be easier to do some actualy debugging... :/ So I doubt it is u-boot misbehaving, but have not yet identified where exactly the problem is... though I have some suspicions in the boot script and thus flash-kernel. live well, vagrant signature.asc Description: PGP signature
Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."
On 2020-11-23, Benedikt Spranger wrote: > On Sun, 22 Nov 2020 14:34:33 -0800 > Vagrant Cascadian wrote: > U-Boot 2020.10+dfsg-1 (Oct 05 2020 - 19:13:28 +) Allwinner > Technology ... > Found U-Boot script /boot.scr > 2417 bytes read in 1 ms (2.3 MiB/s) > ## Executing script at 4fc0 > bootargs: > bootargs=console=ttyS0,115200 quiet Just to be clear, you're using the serial console at ttyS0 at 115200 baud? Or are you expecting HDMI output or some other console output? If you're not expecting to be using the serial console, the problem may be: https://bugs.debian.org/969070 live well, vagrant signature.asc Description: PGP signature
Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."
On Sun, 22 Nov 2020 14:34:33 -0800 Vagrant Cascadian 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=0x4FA0 kernel_addr_r=0x4008 ramdisk_addr_r=0x4FE0 => > 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 +) 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 = 0x4a00 INFO:SPSR = 0x3c9 alloc space exhausted U-Boot 2020.10+dfsg-1 (Oct 05 2020 - 19:13:28 +) Allwinner Technology CPU: Allwinner A64 (SUN50I) Model: Olimex A64-Olinuxino-eMMC DRAM: 1 GiB MMC: mmc@1c0f000: 0, mmc@1c1: 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@1c3 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 4fc0 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=0x4FA0 kernel_addr_r=0x4008 ramdisk_addr_r=0x4FE0 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 0x4008 to 0x4020, end=4185 ## Flattened Device Tree blob at 4fa0 Booting using the fdt blob at 0x4fa0 EHCI failed to shut down host controller. Loading Ramdisk to 48352000, end 49fffa2d ... OK Loading Device Tree to 48348000, end 48351ef2 ... 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
Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."
Control: found 975490 2020.10+dfsg-1+b1
Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."
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 +) > 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 = 0x4a00 > INFO:SPSR = 0x3c9 > alloc space exhausted > > > U-Boot 2020.10+dfsg-1+b1 (Nov 19 2020 - 03:18:11 +) Allwinner > Technology > > CPU: Allwinner A64 (SUN50I) > Model: Olimex A64-Olinuxino-eMMC > DRAM: 1 GiB > MMC: mmc@1c0f000: 0, mmc@1c1: 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@1c3 > 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 4fc0 > 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 0x4008 to 0x4020, end=4185 > ## Flattened Device Tree blob at 4fa0 >Booting using the fdt blob at 0x4fa0 > EHCI failed to shut down host controller. >Loading Ramdisk to 48352000, end 49fffa2d ... OK >Loading Device Tree to 48348000, end 48351ef2 ... 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
Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."
Package: u-boot-sunxi Severity: critical Dear Maintainer, 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. I got into the same situation during an update on an other system to bullseye. Bootlog: ---8<--- U-Boot SPL 2020.10+dfsg-1+b1 (Nov 19 2020 - 03:18:11 +) 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 = 0x4a00 INFO:SPSR = 0x3c9 alloc space exhausted U-Boot 2020.10+dfsg-1+b1 (Nov 19 2020 - 03:18:11 +) Allwinner Technology CPU: Allwinner A64 (SUN50I) Model: Olimex A64-Olinuxino-eMMC DRAM: 1 GiB MMC: mmc@1c0f000: 0, mmc@1c1: 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@1c3 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 4fc0 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 0x4008 to 0x4020, end=4185 ## Flattened Device Tree blob at 4fa0 Booting using the fdt blob at 0x4fa0 EHCI failed to shut down host controller. Loading Ramdisk to 48352000, end 49fffa2d ... OK Loading Device Tree to 48348000, end 48351ef2 ... OK Starting kernel ... ---8<--- Regards Benedikt Spranger
