[BUG] Raxda Rock Pi 4A serial console output stops prematurely

Anand Moon linux.amoon at gmail.com
Thu Nov 27 14:01:01 CET 2025


Hi Quentin,

On Thu, 27 Nov 2025 at 16:24, Quentin Schulz <quentin.schulz at cherry.de> wrote:
>
> On 11/27/25 11:35 AM, Quentin Schulz wrote:
> > Hi Heinrich,
> >
> > On 11/26/25 5:46 PM, Heinrich Schuchardt wrote:
> >> On 11/26/25 16:00, Quentin Schulz wrote:
> >>> Hi Heinrich,
> >>>
> >>> On 11/25/25 7:02 PM, Heinrich Schuchardt wrote:
> >>>> Hello Jagan, hello Heiko,
> >>>>
> >>>> When testing U-Boot origin/master on my Raxda Rock Pi 4A serial
> >>>> console output stops after "PMIC:  RK808". The same can be observed
> >>>> with v2025.01.
> >>>>
> >>>> The serial console works as expected if I disable
> >>>> CONFIG_ROCKCHIP_IODOMAIN.
> >>>>
> >>>
> >>> It is I believe implied here but asking for confirmation. The board
> >>> doesn't actually boot right? It's not that the serial console is
> >>> gone, it's that the device is stuck?
> >>
> >> Hello Quentin,
> >>
> >> Thank you for looking into this.
> >>
> >> The device boots I. But the serial console output becomes mute and I
> >> cannot send keystrokes via the serial console.
> >>
> >
> > Uh. That is *weird*.
> >
> >>>
> >>>> The problem seems to be specifically related to the bt656-supply.
> >>>> Removing the line below also fixes serial console output:
> >>>>
> >>>> diff --git a/drivers/misc/rockchip-io-domain.c b/drivers/misc/
> >>>> rockchip- io-domain.c
> >>>> index a0573c52193..b0d78f2d4b4 100644
> >>>> --- a/drivers/misc/rockchip-io-domain.c
> >>>> +++ b/drivers/misc/rockchip-io-domain.c
> >>>> @@ -239,7 +239,7 @@ static const struct rockchip_iodomain_soc_data
> >>>> soc_data_rk3328 = {
> >>>>   static const struct rockchip_iodomain_soc_data soc_data_rk3399 = {
> >>>>          .grf_offset = 0xe640,
> >>>>          .supply_names = {
> >>>> -               "bt656-supply",         /* APIO2_VDD */
> >
> > Reading the code and this diff again, this you shouldn't do at all. The
> > offset in the array is the bit offset for the IO domain setting in the
> > GRF at offset 0xe640. So by removing this line, you configured APIO2 IO
> > domain with APIO5 settings (audio-supply).
> >
> > It would be better to write NULL instead, so that the others are tried
> > and we can pinpoint the faulty one.
> >
> >>>>
> >>>
> >>> The UART2 (which I assume is the serial you're using for the console)
> >>> isn't on that IO domain. And there doesn't seem to be anything
> >>> important to booting on APIO2 domain according to Rock 4A schematics[1].
> >>>
> >>> bt656-supply also doesn't seem to be anything special. LDO5 (vcc_3v0)
> >>> on RK808, which is using VCC10 (vcc10-supply) which is a fixed
> >>> regulator whose parent supply is also a fixed regulator. So I am not
> >>> sure what could be going wrong there.
> >>
> >> In the schema LD05 on the RK808 is connected to VCC_1V5.
> >>
> >
> > Sorry, I meant to say LDO8.
> >
> >> With any of the following values I can enter commands via serial
> >> console but still get no output. So none of the voltages seems to be
> >> the correct one.
> >>
> >> diff --git a/dts/upstream/src/arm64/rockchip/rk3399-rock-pi-4.dtsi b/
> >> dts/upstream/src/arm64/rockchip/rk3399-rock-pi-4.dtsi
> >> index 046dbe32901..f15b5b63815 100644
> >> --- a/dts/upstream/src/arm64/rockchip/rk3399-rock-pi-4.dtsi
> >> +++ b/dts/upstream/src/arm64/rockchip/rk3399-rock-pi-4.dtsi
> >> @@ -517,7 +517,7 @@
> >>
> >>   &io_domains {
> >>          audio-supply = <&vcca1v8_codec>;
> >> -       bt656-supply = <&vcc_3v0>;
> >> +       bt656-supply = <&vcc_1v5>;
> >> or
> >> +       bt656-supply = <&vcc_0v9>;
> >> or
> >> +       bt656-supply = <&vcc_1v8>;
> >>
> >>>
> >>> RK3399 Puma and RockPro64 have APIO2 set to 1.8V vs 3.0V for Radxa
> >>> Rock 4A. Puma boots master reaches U-Boot CLI with the IO domain
> >>> driver compiled in.
> >>>
> >>> Can you check the error paths (all the ones with a continue;) in
> >>> rockchip_iodomain_probe()? Which ones do you enter for which supply?
> >>>
> >>> Not sure where to start debugging tbh.
> >>
> >> I found the driver by setting CONFIG_LOG=y and log level 7.
> >>
> >> Here is how the console output ends. Do you have access to a board or
> >> do you need further debug output?
> >>
> >> ofnode_find_subnode: regulator-state-mem: regulator-state-mem:
> >> regulator-state-mem
> >> regulator-state-mem
> >> ofnode_read_bool: regulator-off-in-suspend: true
> >> ofnode_read_u32_index: regulator-suspend-microvolt: of_read_u32_index:
> >> regulator-suspend-microvolt: (not found)
> >> ofnode_read_prop: assigned-clock-rates: <not found>
> >> ofnode_read_u32_index: regulator-min-microvolt: of_read_u32_index:
> >> regulator-min-microvolt: (not found)
> >> ofnode_read_u32_index: regulator-max-microvolt: of_read_u32_index:
> >> regulator-max-microvolt: (not found)
> >> ofnode_read_u32_index: regulator-init-microvolt: of_read_u32_index:
> >> regulator-init-microvolt: (not found)
> >> ofnode_read_u32_index: regulator-min-microamp: of_read_u32_index:
> >> regulator-min-microamp: (not found)
> >> ofnode_read_u32_index: regulator-max-microamp: of_read_u32_index:
> >> regulator-max-microamp: (not found)
> >> ofnode_read_u32_index: regulator-ramp-delay: of_read_u32_index:
> >> regulator-ramp-delay: (not found)
> >> ofnode_read_bool: regulator-force-boot-off: false
> >> ofnode_find_subnode: regulator-state-mem: regulator-state-mem:
> >> regulator-state-mem
> >> regulator-state-mem
> >> ofnode_read_bool: regulator-off-in-suspend: true
> >> ofnode_read_u32_index: regulator-suspend-microvolt: of_read_u32_index:
> >> regulator-suspend-microvolt: (not found)
> >> ofnode_read_prop: assigned-clock-rates: <not found>
> >> ofnode_read_u32_index: regulator-min-microvolt: of_read_u32_index:
> >> regulator-min-microvolt: (not found)
> >> ofnode_read_u32_index: regulator-max-microvolt: of_read_u32_index:
> >> regulator-max-microvolt: (not found)
> >> ofnode_read_u32_index: regulator-init-microvolt: of_read_u32_index:
> >> regulator-init-microvolt: (not found)
> >> ofnode_read_u32_index: regulator-min-microamp: of_read_u32_index:
> >> regulator-min-microamp: (not found)
> >> ofnode_read_u32_index: regulator-max-microamp: of_read_u32_index:
> >> regulator-max-microamp: (not found)
> >> ofnode_read_u32_index: regulator-ramp-delay: of_read_u32_index:
> >> regulator-ramp-delay: (not found)
> >> ofnode_read_bool: regulator-force-boot-off: false
> >> ofnode_find_subnode: regulator-state-mem: regulator-state-mem:
> >> regulator-state-mem
> >> regulator-state-mem
> >> ofnode_read_bool: regulator-off-in-suspend: true
> >> ofnode_read_u32_index: regulator-suspend-microvolt: of_read_u32_index:
> >> regulator-suspend-microvolt: (not found)
> >> ofnode_read_prop: assigned-clock-rates: <not found>
> >> ofnode_read_prop: assigned-clock-rates: <not found>
> >> ofnode_read_u32_index: bt656-supply: of_read_u32_index: bt656-supply:
> >> 0x7a (122)
> >> rockchip_iodomain io-domains: bt656-supply: Regulator LDO_REG8 at
> >> 3000000 uV
> >> ofnode_read_u32_index: audio-supply: of_read_u32_index: audio-supply:
> >> 0x91 (145)
> >> rockchip_iodomain io-domains: audio-supply: Regulator LDO_REG1 at
> >> 1800000 uV
> >> ofnode_read_u32_index: sdmmc-supply: of_read_u32_ at L@@p0b at HHb```Hp0 p0   $
> >>
> >
> > This seems to highlight the issue is rather audio-supply.
> >
> > And indeed, audio-supply should be vcc_3v0 and not vcca1v8_codec.
> >
>
> Mmmmmm, upstream kernel has 8240e87f16d1 ("arm64: dts: rockchip: fix
> audio-supply for Rock Pi 4"). So it seems it "fixed" something.
>
> So before I send a revert to the kernel and start an endless thread, can
> you test locally that the following indeed fixes it?
>
> diff --git a/arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi
> b/arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi
> index 4861574636e..dccc469a507 100644
> --- a/arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi
> @@ -14,6 +14,10 @@
>         };
>   };
>
> +&io_domains {
> +       audio-supply = <&vcc_3v0>;
> +};
> +
>   &sdhci {
>         cap-mmc-highspeed;
>         mmc-ddr-1_8v;
>
Thanks. I am having the same issue with my Radxa Rock Pi 4 B Plus.

But I am booting from SPI flash, so I cannot stop this board in the
U-Boot prompt.

Is there any other way to flash the SPI flash u-boot-rockchip-spi.bin image
in the user space to spi flash? using dd coammnd

>From the schematics, it has W25Q64FWZPIG

[1] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/rockpi4_v13_sch_20181112.pdf

I have tried to enable SPI flash, but it is not getting detected on
the board in userspace.

$ git diff arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b-plus.dts
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b-plus.dts
b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b-plus.dts
index 9c741d1a3047..d18b59ddaa1d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b-plus.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b-plus.dts
@@ -42,6 +42,16 @@ &sound {
        hp-det-gpios = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
 };

+&spi1 {
+       status = "okay";
+
+       flash at 0 {
+               compatible = "winbond,w25q64", "jedec,spi-nor";
+               reg = <0>;
+               spi-max-frequency = <108000000>;
+       };
+};
+
 &uart0 {
        status = "okay";

Can you share some input on how to resolve this issue?

>
> Cheers,
> Quentin

Thanks
-Anand


More information about the U-Boot mailing list