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

Quentin Schulz quentin.schulz at cherry.de
Thu Nov 27 11:45:25 CET 2025 

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;


Cheers,
Quentin

More information about the U-Boot mailing list