On 11/30/25 1:12 PM, Anand Moon wrote:
Hi FUKAUMI,
On Sun, 30 Nov 2025 at 13:24, FUKAUMI Naoki <[email protected]> wrote:
Hi Anand,
On 11/30/25 16:27, Anand Moon wrote:
Hi FUKAUMI
On Sat, 29 Nov 2025 at 15:22, FUKAUMI Naoki <[email protected]> wrote:
Hi Anand,
On 11/29/25 16:25, Anand Moon wrote:
Hi FUKAUMI,
On Sat, 29 Nov 2025 at 10:09, FUKAUMI Naoki <[email protected]> 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@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@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@rockpi4b:~$ cat /proc/mtd
dev: size erasesize name
alarm@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
