[BUG] Raxda Rock Pi 4A serial console output stops prematurely
Quentin Schulz
quentin.schulz at cherry.de
Thu Nov 27 15:14:30 CET 2025
Hi Heinrich,
On 11/27/25 1:50 PM, Heinrich Schuchardt wrote:
> On 11/27/25 11:45, Quentin Schulz 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;
>>
>>
>> Cheers,
>> Quentin
>
> Hello Quentin,
>
> With the diff applied my U-Boot serial console works.
>
> I checked the u-boot.dtb: audio-supply now points to
> LDO_REG8 { regulator-name = "vcc_3v0";}
> as expected.
>
Thanks for testing.
OK that's good. I'll send the revert soon.
My hunch is that the original issue that prompted this commit in the
kernel was likely an IO domain issue. I've seen this happen on a camera
clock signal on a PX30 device where if the camera is probed before the
IO domain is configured, it will fail to probe due to the IO domain
being misconfigured and messing up the clock signal. If you boot a
recent U-Boot (one with IO domain support) and then boot into the
kernel, this isn't an issue anymore as the IO domain will have been
properly setup before switching to the kernel. Of course, this only
works if the supplies for the IO domains are not changing at runtime
(but on Rock 4 variants that doesn't seem to be intended or even
possible). Another possibility is that the ES8316 is missing control of
its PVDD, DVDD and AVDD supplies in the DT and somehow changing to this
new supply brought vcca1v8_codec up (which is DVDD and AVDD).
I'll be sending the revert to the kernel ML and we can discuss there to
have more eyes on it :)
Cheers,
Quentin
More information about the U-Boot
mailing list