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

Mon Dec 1 11:40:40 CET 2025

On 11/30/25 1:12 PM, Anand Moon wrote:
> Hi FUKAUMI,
> 
> On Sun, 30 Nov 2025 at 13:24, FUKAUMI Naoki <naoki at radxa.com> wrote:
>>
>> Hi Anand,
>>
>> On 11/30/25 16:27, Anand Moon wrote:
>>> Hi FUKAUMI
>>>
>>> On Sat, 29 Nov 2025 at 15:22, FUKAUMI Naoki <naoki at radxa.com> wrote:
>>>>
>>>> Hi Anand,
>>>>
>>>> On 11/29/25 16:25, Anand Moon wrote:
>>>>> Hi FUKAUMI,
>>>>>
>>>>> On Sat, 29 Nov 2025 at 10:09, FUKAUMI Naoki <naoki at radxa.com> wrote:
>>>>>>
>>>>>> Hi Anand,
>>>>>>
>>>>>> On 11/28/25 14:50, Anand Moon wrote:
>>>>>>> Hi Heinrich,
>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>> https://wiki2.radxa.com/Rockpi4/dev/usb-install
>>>>>>>> has some guidance how to avoid booting from SPI NOR flash.
>>>>>>>>
>>>>>>> Thanks for your tip.
>>>>>>>
>>>>>>> I've attempted this method, but it hasn't worked for me.
>>>>>>> Could you provide the SPI details for this board so I can map it in driver code
>>>>>>> and from userspace and then attempt to erase or reflash the image?
>>>>>>>
>>>>>>> on my board
>>>>>>> [    1.282609] mmcblk0boot0: mmc0:0001 SLD64G 4.00 MiB
>>>>>>> [    1.285862] spi-nor spi1.0: unrecognized JEDEC id bytes: ff ff ff ff ff ff
>>>>>>
>>>>>> Are you using dts with "audio-supply = <&vcc_3v0>;"? It should fix SPI too.
>>>>>>
>>>>> Thanks for your tip.
>>>>>
>>>>> I have applied the patch from FUKAUMI, and now my console output has
>>>>> started working
>>
>> How did you use patched dts? And what does "my console output has
>> started working" mean?
>>
>>>>>> 1. Make u-boot-rockchip.bin with "audio-supply = <&vcc_3v0>;"
>>>>>> 2. Write it to microSD card
>>>>>> 3. Insert it
>>>>>> 4. Kill SPI flash
>>>>>> 5. Boot U-Boot from SD card
>>>>>> 6. Revert 4.
>>>>>> 7. Try "sf probe" "sf erase"
>>>>>>
>>>>> Yes, I have tried these steps (4 Kill SPI flash) ->
>>>>> I have shortened the SPI1_CLK and GNG in the GPIO header
>>>>> But this board first boots from SPI flash, I don't know the reason.
>>>>>
>>>>> I noticed your patch references the W25Q128.
>>>>> Did you get this device detection in userspace?
>>>>>
>>>>> This output is from your patch.
>>>>> => led blue:status off
>>>>> => sf probe
>>>>> SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
>>>>> => led blue:status on
>>>>> => sf probe
>>>>> jedec_spi_nor flash at 0: unrecognized JEDEC id bytes: ff, ff, ff
>>>>> Failed to initialize SPI flash at 1:0 (error -2)
>>>>>
>>>>> Could this explain why I’m unable to detect the device from userspace?
>>>>
>>>> What happens if you lower the SPI clock?
>>>> e.g.
>>>>     spi-max-frequency = <10000000>;
>>>>
>>> Thanks for your input, but I have a bad old U-Boot in my SPI chip,
>>> which blocks the UART. I need to erase the SPI chip externally
>>> or erase the chip from user space.
>>
>> If you can use patched dts on Linux, please try lower frequency and see
>> spi-nor found or not on Linux. W25Q64FW max frequency is 104MHz, not 108MHz.
>>
> Thanks,  I have tried all the things you suggested
> 
> alarm at rockpi4b:~$ dmesg | grep spi
> [    0.000000] Kernel command line: console=ttyS2,1500000
> root=LABEL=ROOT_MNJRO rw rootwait audit=0 splash
> plymouth.ignore-serial-consoles dyndbg="file
> drivers/mtd/spi-nor/spi-nor.c +p"
> [    0.000000] Unknown kernel command line parameters "splash
> dyndbg=file drivers/mtd/spi-nor/spi-nor.c +p", will be passed to user
> space.
> [    1.293692] spi-nor spi1.0: unrecognized JEDEC id bytes: ff ff ff ff ff ff
> [    1.435572]     dyndbg=file drivers/mtd/spi-nor/spi-nor.c +p
> alarm at rockpi4b:~$ cat /proc/mtd
> dev:    size   erasesize  name
> alarm at rockpi4b:~$
> 
> Yes, I have applied your suggestion and built the kernel
> Still, I am not able to detect the SPI flash in user space.
> 
> Here is the bootlogs [1] https://pastebin.com/25fCqwRT
> My console works after I apply your patch to the kernel.
> 
> U-Boot TPL 2025.10-1 (Oct 31 2025 - 11:12:15)
> lpddr4_set_rate: change freq to 400MHz 0, 1
> Channel 0: LPDDR4, 400MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> Channel 1: LPDDR4, 400MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> 256B stride
> lpddr4_set_rate: change freq to 800MHz 1, 0
> Trying to boot from BOOTROM
> Returning to boot ROM...
> 
> U-Boot SPL 2025.10-1 (Oct 31 2025 - 11:12:15 +0000)
> Trying to boot from MMC1

I believe this means you booted from eMMC. (MMC2 should be SD card as 
far as I remember)

When you boot from SPI flash, you should see "Trying to boot from SPI" 
first, if it fails then it'll try to boot from eMMC and then SD card. 
This is due to

u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc;

in arch/arm/dts/rk3399-u-boot.dtsi + SPL_SPI* symbols in your .config.

> ## Checking hash(es) for config config-1 ... OK
> ## Checking hash(es) for Image atf-1 ... sha256+ OK
> ## Checking hash(es) for Image u-boot ... sha256+ OK
> ## Checking hash(es) for Image fdt-1 ... sha256+ OK
> ## Checking hash(es) for Image atf-2 ... sha256+ OK
> ## Checking hash(es) for Image atf-3 ... sha256+ OK
> ## Checking hash(es) for Image atf-4 ... sha256+ OK
> load_simple_fit: Skip load 'atf-5': image size is 0!
> 
> 
> U-Boot 2025.10-1 (Oct 31 2025 - 11:12:15 +0000)
> 
> SoC: Rockchip rk3399
> Reset cause: POR
> Model: Radxa ROCK Pi 4A
> DRAM:  4 GiB (total 3.9 GiB)
> PMIC:  RK808
> 
> You see, I could not control the UART with the key pressed.

Because you don't have the audio-supply patch for this U-Boot maybe? Or 
you didn't actually flash your newly compiled U-Boot on the device this 
U-Boot loads from.

Cheers,
Quentin