Hi Andre,
On 14.12.24 г. 4:19 ч., Andre Przywara wrote:
On Thu, 12 Dec 2024 11:19:06 +0200
Leon Anavi<[email protected]> wrote:
Hi Leon,
On 11.12.24 г. 23:53 ч., Andre Przywara wrote:
On Mon, 9 Dec 2024 23:08:19 +0200
Leon Anavi<[email protected]> wrote:
Hi Leon,
thanks for the report!
Commit ffb0294 from 12 November 2023 that simplifies early PMIC setup
conditions causes issues on Cubieboard 4 and Merrii A80 Optimus with
Allwinner A80 SoC (sun9i). The commit was introduced with U-Boot 2024.01
(rc3) and remains as of today. Because of it both of these boards hang at:
Starting kernel ...
That's odd, how do you boot the kernel, exactly?
I just tried mainline U-Boot (via FEL), with:
=> setenv bootargs "console=ttyS0,115200n8 earlycon"
=> bootz $kernel_addr_r $ramdisk_addr_r:300000 $fdtcontroladdr
and it booted fine to the prompt, on a Cubieboard 4 (CC-A80 v1.2).
Kernel was some 6.11-rc6 I just had lying around.
I also compared the code before and after that patch, the only
difference is the order at which DCDC5 gets programmed: before it's
after DCDC4, with the patch it's right after DCDC1.
The rest looked the same.
Booting ffb0294~1 and ffb0294~0 also worked for me, without issues.
So can you please describe how you test that, exactly?
I built core-image-base using the Yocto Project and OpenEmbedded as well
Starting kernel ...
as the meta-sunxi BSP layer. The U-Boot version depends on the Yocto
release. For Scarthgap it is with U-Boot 2024.01 and for the ongoing
development in the master branches the U-Boot version is 2024.10. The
Linux kernel version is 6.6.28. I experienced the same issue with both
U-Boot versions on Merrii A80 Optimus and Lazar (his email is CC)
confirmed the same results on Cubieboard 4. The boot sequence for the
boards in meta-sunxi is through boot.scr generated from the following
boot.cmd:
https://github.com/linux-sunxi/meta-sunxi/blob/master/recipes-bsp/u-boot/files/arm/boot.cmd
In a nutshell, the issue can be reproduced with the following scenario
in U-Boot:
setenv bootargs console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2
rootwait panic=10
So I tried with an SD card now, and I think I see what you mean now.
I was a bit confused first why it would hang for you after "Starting
kernel ...", but I guess it actually doesn't: can you add "earlycon" to your
command line and confirm that the kernel boots, but hangs while waiting
for the secondary cores?
I am still scratching my head how this commit would affect this
behaviour, but this change here seems to fix it for me:
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 29a329f41a2..d7c46eec615 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -582,7 +582,6 @@ void sunxi_board_init(void)
#ifdef CONFIG_AXP_DCDC1_VOLT
power_failed |= axp_set_dcdc1(CONFIG_AXP_DCDC1_VOLT);
- power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
#endif
#ifdef CONFIG_AXP_DCDC2_VOLT
power_failed |= axp_set_dcdc2(CONFIG_AXP_DCDC2_VOLT);
@@ -591,6 +590,9 @@ void sunxi_board_init(void)
#ifdef CONFIG_AXP_DCDC4_VOLT
power_failed |= axp_set_dcdc4(CONFIG_AXP_DCDC4_VOLT);
#endif
+#ifdef CONFIG_AXP_DCDC5_VOLT
+ power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
+#endif
#ifdef CONFIG_AXP_ALDO1_VOLT
power_failed |= axp_set_aldo1(CONFIG_AXP_ALDO1_VOLT);
Can you confirm this?
Yes, thank you. Excellent work! I confirm this solution works. I have
just tested it on Merrii A80 Optimus board. I applied your patch on top
of U-Boot 2024.10.
This fix looks easily mainline-able, as it just restores the old
initialisation order, but I still would like to know why the other
order hangs. Will try to do some experiments.
OK. In the mean time I will contribute your patch to meta-sunxi BSP
layer so that it can be used for the existing U-Boot versions in images
for sun9i machines built using the Yocto project and OpenEmbedded. This
is obviously a far better solution than reverting commit ffb0294.
Thanks,
Leon
Cheers,
Andre
load mmc 0:1 ${fdt_addr_r} ${fdtfile}
load mmc 0:1 ${kernel_addr_r} zImage
bootz ${kernel_addr_r} - ${fdt_addr_r}
Merrii A80 Optimus board boots fine if I revert commit ffb0294.
However, if commit ffb0294 is present in U-Boot the board hangs. Here
is the log: U-Boot 2024.10-dirty (Oct 07 2024 - 14:54:35 +0000)
Allwinner Technology CPU: Allwinner A80 (SUN9I) Model: Merrii A80
Optimus Board DRAM: 2 GiB Core: 62 devices, 18 uclasses, devicetree:
separate WDT: Not starting watchdog@6000ca0 WDT: Not starting
watchdog@8001000 MMC: sunxi_set_reset: (RST#0) unhandled
sunxi_set_reset: (RST#2) unhandled sunxi_set_reset: (RST#1) unhandled
mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1 Loading Environment
from FAT... Unable to read "uboot.env" frommmc0:1... In:
serial@7000000 Out: serial@7000000 Err: serial@7000000 Net: No
ethernet found. Hit any key to stop autoboot: 0 => setenv bootargs
console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootwait
panic=10 => load mmc 0:1 ${fdt_addr_r} ${fdtfile} 24443 bytes read in
3 ms (7.8 MiB/s) => load mmc 0:1 ${kernel_addr_r} zImage 5397992
bytes read in 236 ms (21.8 MiB/s) => bootz ${kernel_addr_r} -
${fdt_addr_r} Kernel image @ 0x22000000 [ 0x000000 - 0x525de8 ] ##
Flattened Device Tree blob at 23000000 Booting using the fdt blob at
0x23000000 Working FDT set to 23000000 Loading Device Tree to
29ff7000, end 29ffff7a ... OK Working FDT set to 29ff7000 Starting
kernel ... Please note that U-Boot is marked with suffix "-dirty"
because of the patches applied by u-boot_%.bbappend from Yocto/OE
layer meta-sunxi but these patches are for other boards and don't
touch the file board/sunxi/board.c. Am I missing something as a
configuration that can make the board boot the same way without
hanging when commit ffb0294 is present?Best regards, Leon
Please also note we fixed d75fa8c80dcfa in U-Boot (DCDC4/5 typo),
and dd36ad71ad6 in the kernel (DCDC5 constraints in the DT).
Cheers,
Andre
Older U-Boot versions without this commit work fine. As a temporary
solution I reverted commit ffb0294 and this way the boards boot
successfully. I tested this work around on Merrii A80 Optimus with
several U-Boot versions, including with U-Boot 2024.10.
Lazar, a friend who owns Cubieboard 4, also tested and confirmed
his board boots with U-Boot 2024.10 if this commit has been
reverted.
How to fix this? Is there a known configuration that can be added
to Merrii_A80_Optimus_defconfig and Cubieboard4_defconfig to avoid
hanging with the existing source code from commit ffb0294 ?
Best regards,
Leon
