I’m testing out the Rock5 B I just got, and the NVMe speed over PCIe gen3 x4 is very nice (seeing 3+ GB/sec with a good NVMe SSD)… so I was trying to get it to boot off NVMe.
microSD booting works, and I can format and mount the NVMe drive I’m using (Kioxia 1TB XG6 SSD), but if I try flashing the debian image to the NVMe drive (using Etcher) then booting off it, the Rock5 just sits and doesn’t boot (no HDMI output, I don’t have serial plugged in).
To get NVMe boot going, I had to flash the SPI Nor using the following method, with some reading between the lines because it’s not the most precise set of instructions…
So it looks like to get NVMe boot working, I need to follow those instructions, and then if I want to revert back to SD/eMMC boot, I’d need to flash it again with the zero image?
If you want to boot from the NVME, follow this tutorial. Do be very careful what you are reading, because it annoyed me for almost a week as i was reading the manual wrongly. https://wiki.radxa.com/Rock5/install/spi
Follow this order:
Step1: Install Tools&Drivers
Step2: Get RK3588 loader and U-Boot images For ROCK 5B
Step3: Boot the board to Maskrom mode
Step4: Write U-Boot images to SPI Nor Flash or erase SPI Nor Flash
What do you mean? I’ve been impressed with the Rock5 so far. Documentation is sometimes a bit rough, but for the most part hardware support’s been decent (certainly better than the RK3366 at this stage in its life). It would be nice if NVMe boot were supported as shipped from the factory, though.
I don’t view this as the SBC vendor failing. More of a Chip producer failing to keep their patches maintained. Basing the entire package on an old Kernel version. It’s kind of like the early Raspberrypi days before the Kernel got full support for the underlying hardware.
This leads to some apps not working due to outdated libraries and such on the version of debian supported.
Yeah, 5.10 has its warts. A lot of little things fixed in 5.13 and 5.15 in particular that affect builds I’ve done on the Pi, and having a kernel that follows mainline closely has been very helpful.
The instructions worked fine for me from a Windows machine. You do have to extract from the rar file with subdirectories - use “7z x”. When you start the Rock5 in Maskrom mode there will be no LED indication, but it will appear in the RKDevTool window. I used dir to get the exact path of the img and bin files so I could paste them into the tool window. Once I got it right, the procedure took about 5 minutes.
Hello, for the SPI, I have done the ‘dd’ method from debian 11 on thé rock 5 and it’s ok.
Rkdevelopptool on Ubuntu on N2+ didn’t make me boot on NVME After.
Boot ok on USB3 too.
Make tests with and without SD card when you boot. It’s liké thé SD must not bé présent for NVME and must bé hère for USB3
Was talking about Radxa’s ‘communication’ ‘strategy’. Rock 5B is now selling and a lot of what customers (and even more experienced people like you) expect to work… hasn’t been fixed since early July when we early adopters got v1.3 of the product.
Also Radxa still favours some Discord crap for ‘community support’ that lacks any log as such questions asked here in the forums might be already answered at another place. Radxa obviously thinks community fragmentation would be a great thing to have.
It is not 5.10 what you’re dealing with but some forward ported 2.6 mess. The version string is 100% irrelevant since this kernel is far far away from any LTS 5.10 kernel.
Ugh, I hate the fact that some people don’t bring back conversations from Discord / Slack / whatever private, non-searchable-history chat apps into forums/GitHub/blog posts/docs/etc.
That’s why I posted here: I want to (a) ask the question, (b) prevent others who search for the same thing from having to ask again, and (c) make it so Google / DDG / et all can pick up this thread and people can find the information without sitting in a semi-private chat thread 24x7.
It’s also a very incomplete build of 5.10 (or 2.6 plus ports, or whatever).
It won’t affect everyone but there is no iscsi support (which means no Longhorn if you are doing K8s). Ceph won’t work either because those modules aren’t built.
Unbelievably the early versions didn’t even enable cgroups (so not Docker/podman/K8s). At least they did an update a month or so ago that fixed that “oversight”.
I’m holding my hopes on the Armbian team coming through here. Their current build looks good. They didn’t include iscsi either - but at least their build tools are solid and you can do your own image (which I did last night to get Longhorn up).
It is not possible to deliver that little. Resolving one bug in open source software (full time professionals needs lets say 3 weeks to nail down) that was not provided or developed by Armbian exceeds donations per one year while you don’t even notice that bug existed or was fixed. Just one small example …
Remember when you will find something doesn’t work …
I have no debate with you on that. The value provided by Armbian is massive and should be supported. It does take a lot of work by many contributors to achieve that success. Other than the Raspberry foundation I can’t think of any group that has done more to drive the small SoC ecosystem forward.
Armbian should be supported by contributing bug reports, code contributions, code reviews and testing. Any supported by Money donations.
My point is this - your negative, whining & complaining attitude on this forum (and on various other forums that you post on) has done absolutely nothing to encourage anyone to make these very contributions. On the contrary. I know about a dozen previous contributors that have now sworn off ever contributing to Armbian again solely because of the negative light you currently shine onto the Armbian community.
I mean really - I come here and make a post that casts Armbian in a positive light and suggests hope that it will allow the Rock5b to become useful. And you choose to respond by attack. Not good form at all. That does not serve the very objective you hope to reach.
My remaining hope is that you can find a way to get past this bitter phase of your association with Armbian. Otherwise, we may in the future be discussing the Armbian project only in the past tense.
