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

[Anand Moon]

Hi Quentin/ FUKAUMI,

On Mon, 1 Dec 2025 at 16:12, Quentin Schulz <quentin.schulz at cherry.de> wrote:
> > 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.
>
My board’s SPI flash is running an outdated firmware that lacks the
auto-supply patch.
which results in the UART console being locked

Thank you for your support and guidance. I understand that this
process is tedious
and challenging to resolve. I will continue debugging the kernel to
enable erasing
the SPI flash.

I have a working development board available for testing and development.
regardless of the SPI flash status.

Please allow me some time to debug this issue.
If I find a solution, I will share the details.

> Cheers,
> Quentin

Thanks
-Anand