Hi Quentin/ FUKAUMI, On Mon, 1 Dec 2025 at 16:12, Quentin Schulz <[email protected]> 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
