Closed windoze closed 9 months ago
Some more possibly useful info took from running SD env:
# Confirm that the SPI flash exists
$ lsblk /dev/mtdblock0
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mtdblock0 31:0 0 16M 0 disk
# NVMe has been written so it now has 2 partitions
$ lsblk /dev/nvme0n1
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 476.9G 0 disk
├─nvme0n1p1 259:1 0 512M 0 part /boot/firmware
└─nvme0n1p2 259:2 0 8.2G 0 part
# Confirm that the SPI loader has been written to SPI flash
$ md5sum /lib/u-boot-friendlyelec-rk3588/rkspi_loader.img
a17f750958ee60c98c21846777de69d2 /lib/u-boot-friendlyelec-rk3588/rkspi_loader.img
$ md5sum /dev/mtdblock0
a17f750958ee60c98c21846777de69d2 /dev/mtdblock0
After the reboot, the following message appears in dmesg
[ 8.207585] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
And the mount
shows:
...
/dev/mmcblk0p2 on / type ext4 (rw, relatime)
...
So I assume it's running the OS on the eMMC instead of NVMe.
I did install on the board flash and it works. Here is my procedure (using another linux PC):
Thanks a lot! It works like a charm.
I use rkdeveloptool
from https://github.com/rockchip-linux/rkdeveloptool, the SPI loader helper from Radxa at https://dl.radxa.com/rock5/sw/images/loader/rock-5b/rk3588_spl_loader_v1.08.111.bin, then flash the rkspi_loader.img
from this project, basically the process same as described at https://wiki.radxa.com/Rock5/install/spi.
After this, the box is able to boot the OS on NVMe.
Seems the action to flash the SPI described in this project (https://github.com/Joshua-Riek/ubuntu-rockchip/wiki/NanoPC-T6#install-the-bootloader-to-the-spi-nor-flash) doesn't work as expected.
Responding for your original issue description. I had the same situation. It helped when I wiped out system on emmc because the preloaded boot loader on emmc was prioritized over the one you place to spi or the boot loader on spi found system on emmc (I dont know). But if you silly wipe out system on emmc it solves the issue. Something like sudo dd if=/dev/zero of=/dev/mmcblk0 bs=100M count=10
. Then it worked. Then after reboot you have to partition and format the emmc so you can use for whatever purposes...
@kezyr I prefer to keep a working OS image on the eMMC as a recovery solution, e.g. when the OS on the NVMe is messed up by accident. 😄
I still don't quite understand why writing to SPI under Linux doesn't work, but rkdeveloptool
does.
Of course the ideal situation is to be able to use UEFI/ACPI, EDK2 recently supported NanoPC T6, I'll give it a shot someday.
This looks solved, correct? Sorry, I was away and catching up on issues now.
Yes, the issue itself is resolved, but I still have the question about why write SPI flash doesn't work under Linux, I have to use rkdeveloptool
to do the task.
I don't follow, /dev/mtdblock0 shows in the operating system and this will allow you to write the SPI flash.
That's exactly my question, dd
to /dev/mtdblock0
doesn't seem to work even it didn't report any error, but writing via maskrom/rkdeveloptool does.
@windoze just an idea - try to do dd from /dev/mtdblock0 afterwards to a new file and compare the contents. It will give a proof that mtdblock0 is actually updated or not.
You could use sha256sum to verify sha value between spi image and mtdblock0.
Or you might be running into uuid conflicts on your emmc do you have the same os image installed?
# Confirm that the SPI loader has been written to SPI flash
$ md5sum /lib/u-boot-friendlyelec-rk3588/rkspi_loader.img
a17f750958ee60c98c21846777de69d2 /lib/u-boot-friendlyelec-rk3588/rkspi_loader.img
$ md5sum /dev/mtdblock0
a17f750958ee60c98c21846777de69d2 /dev/mtdblock0
Already did, you can checkout the 2nd post in this thread.
And two OS images show different info:
$ lsblk /dev/mmcblk0
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk0 179:0 0 230.5G 0 disk
├─mmcblk0p1 179:1 0 3.5M 0 part
├─mmcblk0p2 179:2 0 256K 0 part
├─mmcblk0p3 179:3 0 192K 0 part
├─mmcblk0p4 179:4 0 32K 0 part
├─mmcblk0p5 179:5 0 32K 0 part
├─mmcblk0p6 179:6 0 4M 0 part
└─mmcblk0p7 179:7 0 8M 0 part
$ lsblk /dev/nvme0n1
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 476.9G 0 disk
├─nvme0n1p1 259:1 0 512M 0 part /boot/firmware
└─nvme0n1p2 259:2 0 476.4G 0 part /
So I assume these 2 images shouldn't be the same.
I see. Well, it should be working fine, then I would need to see those sha values differ to show a problem.
I would assume writing the spi flash again would not cause an issue. So I don't think I can do anything here.
That's why I said the original issue is resolved, it did work after re-flash or whatever, I can close this issue if you think no followup needed.
Thanks for your great project, now my T6 can release all potential 😄
Yeah, go ahead and close this issue. I have been working on a few scripts to simplify installing the bootloader to spi flash with a lot of error checking. Hopefully, issues like yours will not happen when the scripts are released.
Thanks again. Closing.
I just got a NanoPC T6 16G with SPI flash, below is what I've done:
But the issue is, it booted into the OS preloaded in eMMC, not the one I just wrote to NVMe.
Not sure what I did wrong.