Please show the contents of file , /boot/hw_intfc.conf when /dev/mmcblk0p4 is mounted on /boot
SPI + NVMe booting(beta)
Shouldn’t really matter but just for reference
#intfc:dtoverlay=pcie-gen2 means you are running at pcie gen1 speeds.
intfc:dtoverlay=pcie-gen2 = gen 2
Found one more issue. Aside from actions in the wiki article you probably need to update fstab, to have /boot on nvme. But still it didn’t help to boot without SD-card.
Any ideas, what’s wrong?
My board has V1.4 on the box and I remember specifically ordering the 1.4 version so I assume I was sent the correct version of Rock Pi 4A.
I have done everything verbatim as described in the installation wiki here:
https://wiki.radxa.com/Rockpi4/Linux_system_runs_on_M.2_NVME_SSD
I’m trying to Write image to SPI flash using mtd tool
After typing YES to execute the rockpi4b_write_spi_flash.sh, I receive the following error:
grep: /proc/mtd: No such file or directory
loader partition on MTD is not found
if I try:
$ sudo gdisk /dev/mtd0
I got error: /dev/mtd0 does not exist.
Do you have red or blue led?
Red led + v1.4 = no SPI
See: https://forum.radxa.com/t/v1-4-vs-1-3-compare/1288/7
Thank you so much for your reply.
The board has white fonts on it, saying “v1.4, Rock Pi 4A”.
I only see a steady bright gree LED light on the board when I turn on electricity. Sometimes I see a smaller blue LED light almost next to the green one, usually blinking. Then there are the green steady and blinking orange LED on the ethernet port. I do NOT see any other LED lights on the board so far.
Everytime I update kernel using:
$ sudo apt-get install -y linux-4.4-latest
I see a lot of things gets updated.
After it’s done updating, I could be following the .conf editing or I could skip it – doens’t matter. As long as I type: sudo reboot, the board shuts off and bricks on me.
Please help. Thanks a bunch.
Do you have spi flash on the board physically?
I had the same issue, and I don’t know why, but there’s no mtd0 when I boot from NVME, but if I disconnect NVME and not from sd card, mtd0 appears.
Now that I think about it – I might be sent a 1.35v board, or just a plain v1.3 board with v1.4 printed on it!
I don’t know what a SPI flash look like so I don’t know if I see one physically on the board.
I have always only connected a SD card to boot into Debian Stretch, so the green LED means electricity is on, and the blue light is from booting from SD card. I don’t see an organge or red LED on the board.
The repeated failue to reboot might be from enabling overlay to flash spi but there is NO spi! So the SD card cannot boot again after following the flash SPI instruction.
I’ll take photos of my board and send them to customer service tomorrow morning so I can get this settled once for all!
Thanks for the pointer.
As to you seeing mtd0 appearing when disconnected from NVME –
I have not connected nvme to the board at all so I don’t know what will happen. I have my nvme in a USB adapter that I purchased from ALLNET. I flashed the latest ARMBIAN based on Debian Buster to it. I’m just waiting to flash SPI so I can boot from this nvme.
I think you are not suppose to see mtd0 once you’ve flashed it and booting from nvme. At that point the job of mtd0, which is spi in this case, is done.
Hi,
have a look at this picture of the board from the Radxa Wiki:
The SPI flash chip is the one in the red rectangle (center bottom). In the picture it is NOT mounted.
HTH
2 Likes
Thank you so much for digging out a nice picture to show me. Here’s a full frontal shot of my Rock Pi 4A. I believe we can see clearly that the SPI flash is properly soldered and mounted there.
So one mystrery is solved. I just need to figure out why when following the instruction verbatim and end up not be able to reboot every single time, haha!
I do NOT have eMMC. I"ve been using several Kingston Canvas Go SD cards.
Any further pointers would be greatly appreciated! I bought everything necessary for a setup of running the Rock ONLY from NVME.
Thanks a bunch!
Yep there is definitely a flash chip there 
But I don’t really understand your issues. I think there are two:
(1) you can’t flash the boot loader to SPI because when doing so you get the error(s):
(2) After updating the kernel, your Rock Pi does not boot anymore:
Is my understanding correct so far?
If so, how do you get your Rock Pi un-bricked when you updated the kernel?
Thank you for taking the time to sort out things for my issue. I’m really grateful!
I have no eMMC. After burning the OS image from wiki.radxa - Debian Stretch, with Etcher, to a Kingston Canvas Go 128GB SD card, on a windows machine, I plug the SD card into ROCK PI 4A, and then plug the power line into the pi. The pi boot with a steady green LED, and then the smaller blue LED next to the green one will flick, from time to time. The screen shows the desktop image of Deiban Stretch without any boot sequence (I also booted Armbian, which has a long loading sequence such as “starting network manager”, “starting MAN db” , etc).
I use LX terminal because this is the only terminal native to Debian stretch for Rock Pi that allows me to change the font size to 20.
If I follow the instruction verbatim, I cannot reboot. This happens everytime I wipe a SD card with Debian image with Etcher, starting the sequence again – same ending.
Here’s the important story line, I guess –
- If I “sudo apt-get install -y linux-4.4-latest” immediatly after the first time boot from a clean Debian image on a SD card, it says there’s no such thing as linux-4.4-latest.
- After adding apt.radxa.com/$DISTRO and adding public key, I update && upgrade with a lot of things installed. At the end it suggests me to reboot when convenient. So I reboot. No problem here.
- If I “sudo apt-get install -y linux-4.4-latest” at this juncture, it installs linux-header-4.4-154-armhf, linux-4.4-latest, and linux-4.4.154-rockchip (something like that). Then Debian stretch reboot without a problem.
- So I proceed with installing rockchip-fstab, rockchip-overlay, and rockpi4b-rk-u-boot-latest. Reboot, everything’s fine.
- If I check to see if there’s a file /boot/hw_intfc.conf, no this file is not there yet.
- Now I install rockpi4-dtbo. It says:
mv: cannot stat ‘/boot/hw_intfc.conf’: no such file or directory
unpacking rockip4-dtbo(1.2)…
setting up rockpi4-dtbo(1.2)…
after this I run update and upgrade again, this time it fetched a “libatomic1” to install. So I agree to let it be installed.
- Now the /boot/hw_intcf.conf is there. I changed intfc.conf to UDART4=off, SPI1=on, and commented out spi1-flash. Save and exit.
- Reboot. It can reboot, but after typing YES to execute the rockpi4b_write_spi_flash.sh, I receive the following error:
So this is the second scenario, which I changed the sequence of the instruction, installing rockpi4-dtbo last and update and upgrade one more time after installing rockpi4-dtbo.
At this point, if I repeat the instruction sequence according to the wiki webpage, it says all those things are already the latest version. If I restart, and redo the .sh command, it gives me the same answer-NO!
The third scenario is that if I skip the linux-4.4-latest entirely, I get the same result when trying to run the flash script: no mtd.
Thank you for all the pointers. Thank you for even just reading this much!
Just found the issue and now has flashed SPI
After installing rockpi4-rk-u-bookt-lastest, I need to go into folder /usr/local/sbin/ to run a script to update boot loader.
After that, I can successfully reboot and run the rockipi4b_write_spi_flash.sh
It seems that the system can only use Debian to boot from nvme. I tried ARMbian that’s based on the latest buster, Armbian_5.90_Rockpi-4b_Debian_buster_default_4.4.182_desktop, and the NVME is not active (no green LED on nvme), although the green LED on the board and the blue little LED are both lit.
1 Like
In that case, Radxa guys, can you check, please, what is needed to boot Ubuntu server?
Excellent. Have you verified you are indeed booting from SPI flash by removing the SD-Card? The NVMe drive has to stay in the Rock Pi.
That is odd. Did you copy the Armbian image to the NVMe drive?
Is the SD-Card still in the Rock Pi at this stage?
I’m not sure when your NVMe drive turns the LED on: (1) as soon as it has power or (2) when it is enumerated and activated by the OS. I suspect (1), but that would mean the boot loader (U-Boot) does not turn on the power. But that can only be true if you’re NOT really booting from SPI flash. 
I really need to be rigorous when I post on this forum – this forum is trainning me to be a good tech writer now, haha.
-
I do not have eMMC, and since I have the M.2 NVME extender I use a shorter ribbon, and the case that I bought really forces me to pay attention if I left a sdcard in the slot. So, no SDCard here, that’s for sure. When I was trying to flash SPI, I only have SDcard attached; now that I have flashed SPI, I only have nvme inserted to the Rock Pi.
-
with NVME being the only medium connected to the ROCK, it’s easy for me to tell what can be booted from nvme–
Debian Stretch downloaded from wiki.radxa.com – this one for sure works
Community image ARBIAN based on stretch – no
Armbian_5.90_Rockpi-4b_Debian_buster_default_4.4.182_desktop - no
I have not tried Ubuntu or Android or LibreElec, etc. I only care about Debian Desktop use.
I see. Well, I’m not really sure what the issue is. My guess is that the boot loader tries to load a kernel that is not there. I.e. there kernel in the image/boot config is named differently than the kernel contained in the image. But I’m not sure about this; at this point it is only a guess.
“the boot loader tries to load a kernel that is not there. I.e. there kernel in the image/boot config is named differently than the kernel contained in the image”
This is what I’m trying to figure out – is there a way to upgrade the kernel in Debian Stretch to Debian Buster? Is there a directory that holds the config file so I just need to copy that file into the new kernel folder and then enjoy the upgraded Debian desktop?
Thank you.
…and here’s my extreme passive cooling scheme for my Rock Pi 4A. Happy Summer Day!
1 Like
Well the easiest way would be to connect the serial debug console and watch the output of the boot loader 
But I guess if you had a USB-serial adapter you would have already done that.