Yeah, I’m trying to use the SPI bootloader (petitboot). But even when I wiped the SPI altogether and didn’t need to hold the button, booting straight to the u-boot on the SD card, I still had that issue.
Now I need to learn more about dtbs and stop just rsync-ing the ones from Debian…
In your case, it should be fairly simple - just find the device tree and bootloader combination that works, and use that.
Generally, device trees are used to describe non-discoverable hardware. Mostly stuff in the SoC, connected via SPI or I2C. It’s a fully independent format, although the values used are passed to the drivers. They should generally be interoperable between kernel version, at least after an SoC or board was mainlined. That interoperability of course excludes kernels customized with extra drivers.
Unless you want to start writing your own, or editing existing, that’s probably all you need to know. And you probably don’t need to, as there seem to exist working ones for your board.
Overall, it’s a fairly nice solution IMO.
I’ve been at work on this for the past couple of days. Seems like I’m getting I/O errors on 2 of my 2GB SD cards. I guess they are so old and have been used so much that it kinda makes sense I can’t read certain sectors anymore. And I’ve written so many images on them that they probably just gave up on living. That, or maybe Manjaro is just awful after updates, I can’t say for sure. Following that, I tried to write OpenBSD for the RockPro64 on another SD card, a 64GB Samsung which hasn’t seen much use. It didn’t work, just like when I had it on the 2GB SD card.
Speaking of Manjaro, I had it on my Odroid N2+ for a while, didn’t bother to switch it up, as it was serving as my temporary NAS, with a 1TB external HDD attached to it. But I remembered how much I hate it after I received a 2.4GB update. I canceled that and today I have installed Void on it. But I did have a KDE edition installed on it, because I initially tried it as a desktop for a little, but the 4GB of RAM felt a bit limiting, which is why I stuck with the Pi.
It may not be exactly a big brain move, because I intend to netboot the N2, but while I’m still using it, at least it should be behaving as I want it to and not kill me with huge updates. But when the time to move the rootfs comes, at least I can just copy the rootfs volume over to the HC4 when I get that thing ready. Which at this point doesn’t seem like a short-term achievement.
I’ll see if I feel like continuing to work on the HC4 this night. I will probably try to get Alpine on the RockPro64, I really want to switch my main router.
At work, we’ve been using SanDisk Silver and they seem real solid for what we do - I even have ran PostgreSQL on one of them for a time, haven’t had any issues so far.
You don’t necessarily have to buy from TME (shipping to US would probably suck), but that’s the link I have at hand.
For the RockPro6, I thought that maybe writing OpenBSD on an SD card using Windows and Rufus would yield a different result, since it worked on the HC4 with petitboot. Too bad, I had my hopes up. It’s behaving the same way, boots, then tries booting efiaa64, then does some counting and arrives to an equals error code 0x1406908, which I cannot find anywhere when looking on the internet.
It was worth a shot, I’ll probably try installing Alpine on the rkpr64 next. It supposedly has the dtb and everything in the generic u-boot aarch64 image, which I can confirm by browsing dtb-lts folder.
In parallel, I’ll be trying to get the HC4 going too. At this point I’m about to give up on it and run the official Ubuntu 20w04 image if it has solid ZFS support. But something in me tells me I should try Gentoo on it.
Personally, I really like having at least some semblance of consistency in my homelab, which is why this process took so long. Having just Alpine or OpenBSD on my router and Void on everything else would have been great. But having to introduce another OS, be it Ubuntu or Debian on the HC4 is driving me insane. If only I knew how to debug why ZFS won’t install on other kernels I’m trying. The closest I got was when I installed Void on the HC4 from an Armbian image and changed the kernel.
The only reason I try to stay clear from disk install distros is because I want something lightweight and something that can run the entire FS from a ramfs or tmpfs. Alpine does that by default, so I usually stuck with it. But technically any distro can be forced to do that. I believe there are tutorials for Gentoo and nixOS to make them diskless / frugal installs. I never actually even bothered to read the Gentoo wiki, even though it may probably help me with my ZFS build issues and may even help me with the frugal install… time to research, I guess.
Have you considered running FreeBSD on RockPro64?
13.1-RELEASE runs well in general and I’ve been run several (with Intel NICs) for months without any issues compared to amd64 (x86-64) hardware. I would highly recommend that you get a A1 rated SD card as that will help performance in general a lot. Sandisk Extreme (A2 rated), Kingston Canvas Select (A1 rated) works well in my experience but you can use slower ones too like Toshiba (now Kioxia) Exceria M302 but you’ll notice the difference in speed. That being said, even though memory cards are more “reliable” (than before) I wouldn’t advice you to hammer the card with writes unless you’re prepared to have backups and replacements on hand. I’ve personally never experience this but I’ve seen MicroSD fail but not due write exhaustion and some are quite “abused” in that regard.
You might also want to want to have a look at the wiki as there are some unresolved issues but most shouldn’t affect your use case:
https://wiki.freebsd.org/arm/RockChip
Edit: Silly typo
Welcome to the forum!
I haven’t really considered FreeBSD, but I wouldn’t mind. What I want to do soon is get a uart connector and debug the rkpr64 with OpenBSD on it. And when I do that, I’ll probably also buy an eMMC module for it. The router is the only thing that I want to be rock solid, the rest can be basically unreliable and have other mechanisms in place through software to make my services reliable.
My HC4 is the only device that will run off of an SD card, which is why I want to figure out how to either run Alpine on it, or do a frugal / diskless install with Void. All the rest of my SBCs will run off of the HC4’s RAID1 setup.
Have you tried any 2.5Gbps cards of any type (Intel, Realtek, Broadcom)? I see that Intel has quite some bugs with their 2.5Gbps controllers, which is a bit sad. I want to grab a card with 2x 2.5Gbps ports for some shenanigans with 2 switches and active-standby ports and using the on-board NIC for CARP.
Thanks! Unfortunately no, I would personally steer clear from Realtek due to reliability concerns and afaik Intel doesn’t offer any dual/quad port controllers for 2.5Gbit yet so you can only get a single port working as RK3399 doesn’t do PCIe bifurcation. Intel i225-V B3 revision should be fine from what I know but it’s not labeled on the product what that revision you’ll get. I don’t think Broadcom have any 2.5GBit controllers and I’ve had no luck using a BCM5708 based card (see arm/RockChip - FreeBSD Wiki )
Unless you plan to do something that logs/writes a lot and exceeds limitations with tmpfs an eMMC module is probably a waste of money.
Keep in mind that Rockchip uses 1.5Mbaud so not all TTL adapters will work, if you want to avoid counterfeit parts and not pay a fortune get something that uses Silicon Labs CP2104. Prolific PL2303 TA also works well but there are counterfeits around and it’s EoL. Here’s a bit more “generic” info USB/Peripherals/Serial - FreeBSD Wiki
If you want some help with FreeBSD feel free to ask
Thought you might like this @ThatGuyB
Not sure if this is a viable thing for ya or too much power for your miser energy stipulations 
the addition of a pcie may add some more functionality to your stacks if needed
Lmao, I posted the official Pine64 blog on the ARM General News Thread last week. The board is supposed to be a Quartz64 with a RISC-V chip and about the same performance, which would be nothing less than amazing.
Maybe in a year or so with at least one distro/OS that has proper (usable) support
Even the high end stuff Sifive is producing is slow molasses specially for certain tasks like javascript.
I mean, ARM SBCs in general aren’t the best Javascript crunching chips.
Ok, I got that wrong. It was comparable specs, not performance.
So it could have the same amount of RAM, I/O etc., just not the same performance. I stand corrected.
Did you ever get around grabbing a TTL adapter?
TTL, as in, a uart connector? I only have a serial rs232 to USB now, but I don’t have any real way to connect that to the boards.
I was also wondering if there’s a way to connect an SBC to another, for example a Pi 2 to a RockPro64. I see no reason why not, they both have a serial connection on some pins, just that I didn’t think of it at the time.
I spent most of my time debugging the TR hypervisor, as I wanted to finish that build and use it for example to get an OpenBSD VM, as I found myself in a situation needing OpenBSD to install OpenBSD on the RockPro64 with a different method. So a VM might come in handy.
That you’re looking for is the type of adapters mentioned in “Buying a serial adapter” from FreeBSD’s Serial wiki-page I linked to (also applies to Windows and Linux). You can connect the adapter to one of your SBCs USB if you want as it’ll work just like any other USB-device.
Just thought it might be something fun with a different SBC architecture to play with for your ventures into SBC. Ive head of RISC-V but need to read more about it.
Outside of Debian, there’s basically 0 support for it. And even then, the SBC has to be supported too, via things like DTB s (device tree blobs) and have a working bootloader.
I know at least FreeBSD invests in RISC-V but relies on mainline U-Boot and Linux kernel for DTB (in general) 
I doubt you’ll see any support from Debian “mainline” anytime soon
Geeze looking at SBC prices it even seems that intel SBC’s are cheaper than ARM depending on the manufacturer… So crazy. Hopefully more Pi’s will drop soon.
