[BUG] Raxda Rock Pi 4A serial console output stops prematurely
Quentin Schulz
quentin.schulz at cherry.de
Thu Nov 27 15:01:10 CET 2025
Hi Anand,
On 11/27/25 2:01 PM, Anand Moon wrote:
> 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.
>
Not sure why booting from SPI flash means you cannot stop the board in
U-Boot?
> 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
flashcp u-boot-rockchip-spi.bin /dev/mtdX
I believe?
>
> 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.
Are you sure you have the driver for the SPI controller, MTD,
MTD_SPI_NOR, ... available?
You can check from a running system by looking at /proc/config or
/proc/config.gz
(you can grep in config.gz with zgrep)
>
> $ 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?
>
Looks ok to me.
Cheers,
Quentin
More information about the U-Boot
mailing list