From: Andre Przywara <andre.przywara@arm.com>
To: Leon Anavi <leon.anavi@konsulko.com>,
linux-sunxi <linux-sunxi@lists.linux.dev>
Cc: u-boot@lists.denx.de, lhristov@gmail.com
Subject: Re: [PATCH 1/3] sunxi: board: simplify early PMIC setup conditions
Date: Sat, 14 Dec 2024 02:19:50 +0000 [thread overview]
Message-ID: <20241214021950.5013865a@minigeek.lan> (raw)
In-Reply-To: <e77f6b37-7d50-4f3d-9bed-6d3e39effb4c@konsulko.com>
On Thu, 12 Dec 2024 11:19:06 +0200
Leon Anavi <leon.anavi@konsulko.com> wrote:
Hi Leon,
> On 11.12.24 г. 23:53 ч., Andre Przywara wrote:
> > On Mon, 9 Dec 2024 23:08:19 +0200
> > Leon Anavi<leon.anavi@konsulko.com> 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?
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.
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" from mmc0: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
next prev parent reply other threads:[~2024-12-14 2:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-09 21:08 [PATCH 1/3] sunxi: board: simplify early PMIC setup conditions Leon Anavi
2024-12-11 21:53 ` Andre Przywara
2024-12-12 9:19 ` Leon Anavi
2024-12-14 2:19 ` Andre Przywara [this message]
2024-12-14 11:40 ` Leon Anavi
-- strict thread matches above, loose matches on Subject: below --
2023-10-18 15:50 [PATCH 0/3] power: add AXP313 PMIC support Andre Przywara
2023-10-18 15:50 ` [PATCH 1/3] sunxi: board: simplify early PMIC setup conditions Andre Przywara
2023-10-21 6:34 ` Jernej Škrabec
2023-10-21 21:19 ` Andre Przywara
2023-10-31 6:42 ` Jaehoon Chung
2023-10-31 11:54 ` Andre Przywara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241214021950.5013865a@minigeek.lan \
--to=andre.przywara@arm.com \
--cc=leon.anavi@konsulko.com \
--cc=lhristov@gmail.com \
--cc=linux-sunxi@lists.linux.dev \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox