December 7, 2025

Orange Pi R1 Plus LTS (RK3328) - putting boot files on NAND

(This did not end well, but here is the story.)

The board has 16M of NAND memory in a 128 Mbit spi flash chip.

What about boot order? I don't want to put bootable data onto nand and then find it always boots that and I cannot boot an SD card.

Boot order is covered in 1.2 of the TRM. The order is:

It looks like we may have a problem with SDMMC last. It really should be first, and this is a bad choice by Rockchip.

What we can probably do is to put U-boot onto NAND flash, then get to the U-boot prompt and use U-boot to write over the contents of NAND. It may even be possible to just tell that U-boot to boot from SD. This will require some experimenting.

U-boot has this command to fill RAM memory: 

mw[.b, .w, .l] address value [count]
Then we could use this command to write that block onto NAND. 
nand write   :

Avoid padding in my boot image

Currently my boot image is 33M (just U-boot mind you), making the idea of putting this on NAND a "no go". The file u-boot-rockchip.bin is 9374208 -- under 10M, so it would fit, how does it get bloated up to 33M? The file bl31.elf (which is contained in the above) is 762816 bytes.

The image is generated via: 

dd if=u-boot/u-boot-rockchip.bin of=tmp.img seek=64 conv=notrunc
truncate -s 32M tmp.img
It is all about the "truncate" command, which pads the image to 32M so it can be properly concatenated with the linux image which should follow. If I omit the truncate command, I get: 
dd if=u-boot/u-boot-rockchip.bin of=zzz.img seek=64 conv=notrunc
18309+0 records in
18309+0 records out
9374208 bytes (9.4 MB, 8.9 MiB) copied, 0.0400793 s, 234 MB/s

-rw-r--r--  1 tom tom  9406976 Dec  7 09:05 zzz.img
This will clearly fit nicely into my 16M NAND.

Give it a try

I insert my Debian "forky" micro SD card and interrupt the boot to get the U-boot prompts. Then I type: 
run linux
I login as root with password "er3nae". I has obtained IP address 192.168.0.39 via dhcp, which is host petunia as seen from my desktop linux system.
Flash is available as: 
root@debian:/dev# ls -l mtd*
crw------- 1 root root 90, 0 Dec  4 20:50 mtd0
crw------- 1 root root 90, 1 Dec  4 20:50 mtd0ro
At this point I have choices. I could just do this: 
cd /dev
dd if=mmcblk0 of=mtd0 bs=1M count=10
And this is easy, so I do it. It takes quite a while (almost a full minute). Serial flash is pretty slow apparently, at least on writes. 
dd if=mmcblk0 of=mtd0 bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 30.6112 s, 343 kB/s
sync
halt
This halts linux and powers down the board. I remove the micro SD card and cycle power to get: 
U-Boot TPL 2025.10johang-dirty (Nov 01 2025 - 02:07:18)
LPDDR3, 333MHz
BW=32 Col=10 Bk=8 CS0 Row=14 CS1 Row=14 CS=2 Die BW=16 Size=1024MB
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2025.10johang-dirty (Nov 01 2025 - 02:07:18 +0000)
Trying to boot from SPI
Error: -22
Trying to boot from MMC2
Card did not respond to voltage select! : -110
spl: mmc init failed with error: -95
Error: -95
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
Well, this is disappointing. We can't even get to U-boot. I put the debian linux SD card back in and hit the reset button. It boots up! I really expected the board to be bricked. I have an idea how this worked with NOR flash being first in the boot order, but I need to try an experiment to be sure.

I hit reset and get to the U-boot prompt and use "run linux" to get Debian running again.

On my linux desktop, I read from the SD card that has my recently build U-boot setup and copy it to "petunia". 

dd if=/dev/sdc of=tom_boot.img bs=1M count=10
scp tom_boot.img root@petunia:
Then on the RK3328 debian system, I log in and do this: 
dd if=tom_boot.img of=/dev/mtd0 bs=1M
I halt debian, remove the card, and now it doesn't boot at all!

Yes, now it is bricked indeed. It won't boot with either of my cards, or without any card. This is unfortunate.

Attack the hardware

The SPI nor chip is on the bottom of the board. An 8 pin device - U54. Pin 7 is an active low reset signal, labeled "HOLD*" on the schematic. It is tied to Pin 8 which is Vcc and this can easily be seen under the microscope.

My idea is to use a very tiny (0.30mm) carbide drill in a dremel tool to cut this trace, then pull it to ground to disable the SPI chip. This should allow us to boot from the SD card, but with the chip disabled, it will be impossible to write zeros to SPI and "fix" the chip. But the board is useless as it is, so that would at least be a step forward.

The tiny drill cuts faster than you expect with no pressure. Any pressure would just snap the drill. The real problem is cutting too deep into this multilayer board.

With just the trace cut, the problem is not yet solved. We get the red status LED and lights on the ethernet RJ45. But nothing on the console uarts.

Now we do the solder work to tie pin 7 to ground (pin 4). I do that, and the board shuts down. No lights at all.

So now, no more "Mr. Nice Guy". We turn on the hot air solder rework station and remove the SPI chip entirely. Sad to say, it fractures during removal and will need to be discarded,

Now we are back on the air! It boots and runs linux just fine now from the compact-SD card.

Conclusion

I blame all this entirely on the stupid boot order chosen by Rockchip in their bootrom code. The SDmmc device should absolutely be the first thing so that whenever an SD card is present, it boots from it.

Two things I don't understand in all of this. Why did my second copy of the boot image brick the board? Why did cutting pin 7 loose and pulling it to ground freeze up the board?

All this was a less than fulfilling way to spend an afternoon. However, I have the board back in a state where it is entirely useful.

Someday, if I had nothing better to do, I could buy some SPI flash chips and use my hot air station to reinstall one on the board. I think the pad for pin 2 pulled off, and I would have to see if I could install a rat-wire to connect to it. The chances of me actually doing any of this are almost nil.

Have any comments? Questions? Drop me a line!

Tom's electronics pages / tom@mmto.org