Experiences like this will prevent me from buying any more devices from PINE64. The hardware has great potential but because it doesn’t receive first-party support it’s always a battle to get something that makes full use of its potential. I wrote about my experience with it when I got mine in 2018. Since then I’ve found it’s an ok headless ARM test device running Arch Linux ARM but I will avoid getting any new PINE64 hardware (having also been sucked in by the pine phone and its keyboard).
Honestly after trying several of those boards - odroid c4, rpi 3-4-400, radxa rock pi 4 and couple of pine64 (h64 and rockpro64) I like pine64 the most, it was the easiest to work with even though I’ve used OpenBSD that is not extermely popular. As any other chip rk3399 and others - they have their peculiarity but that comes not from potato vendor but just from lack of a proper standartization (dtb/uefi is a thing but still requires a lot of manual interventions.
I recently went through most of this agony trying to get a RockPro64 to work with OpenBSD and a PCIe NIC, and I was ultimately unsuccessful. Super frustrating.
PCIe on the rockpro64 is a lot less coherent than on amd64 systems, so drivers that don’t do dma syncs correctly will have problems. I recently fixed aq(4) so it works properly on rockpro64, though I haven’t committed some of that work yet. Which nic/driver were you using?
It is all potentially fixable, but it takes a lot of time and gumption to push through. There’s a lot of pieces of things out there, and putting it all together can be quite a challenge.
https://tow-boot.org/ does that. The recommended installation approach is to install that to your board’s SPI, which can then boot generic arm64 images.
It’s used by ~most Linux mobile distributions, and allows the distributions to publish a single arm64 image.
It doesn’t support Rock64 yet, but the developer recently suggested it wouldn’t be much work, and they’d give it go, if others could help verify it: https://github.com/Tow-Boot/Tow-Boot/issues/151
How did I figure this out? Why, through the power of friendship! No seriously, I just asked my friend and she told me to do this and it worked. I don’t know where else you’d find this information on your own.
Experiences like this will prevent me from buying any more devices from PINE64. The hardware has great potential but because it doesn’t receive first-party support it’s always a battle to get something that makes full use of its potential. I wrote about my experience with it when I got mine in 2018. Since then I’ve found it’s an ok headless ARM test device running Arch Linux ARM but I will avoid getting any new PINE64 hardware (having also been sucked in by the pine phone and its keyboard).
Honestly after trying several of those boards - odroid c4, rpi 3-4-400, radxa rock pi 4 and couple of pine64 (h64 and rockpro64) I like pine64 the most, it was the easiest to work with even though I’ve used OpenBSD that is not extermely popular. As any other chip rk3399 and others - they have their peculiarity but that comes not from potato vendor but just from lack of a proper standartization (dtb/uefi is a thing but still requires a lot of manual interventions.
I recently went through most of this agony trying to get a RockPro64 to work with OpenBSD and a PCIe NIC, and I was ultimately unsuccessful. Super frustrating.
PCIe on the rockpro64 is a lot less coherent than on amd64 systems, so drivers that don’t do dma syncs correctly will have problems. I recently fixed aq(4) so it works properly on rockpro64, though I haven’t committed some of that work yet. Which nic/driver were you using?
It’s a dual-port Intel 82576
I’m not sure if you’re still interested in having this work, but I posted a diff here:
https://marc.info/?l=openbsd-tech&m=165645184229510&w=2
this hasn’t been committed yet, it’s a bit of a hack and we still need to figure out how much of it we should do properly instead.
It is all potentially fixable, but it takes a lot of time and gumption to push through. There’s a lot of pieces of things out there, and putting it all together can be quite a challenge.
Nice writeup!
The whole arm board/SoC thing is a mess now. I guess we need a powerhouse of the IBM in the early PC era.
https://tow-boot.org/ does that. The recommended installation approach is to install that to your board’s SPI, which can then boot generic arm64 images.
It’s used by ~most Linux mobile distributions, and allows the distributions to publish a single arm64 image.
Oh tow-boot looks really good thank you for the link!
It doesn’t support Rock64 yet, but the developer recently suggested it wouldn’t be much work, and they’d give it go, if others could help verify it: https://github.com/Tow-Boot/Tow-Boot/issues/151
Consider offering to verify, if you’re keen!
I setup a RockPro64 as a router using FreeBSD and a quad port PCIe NIC and it’s working great. Only issue I had was with the on board NIC being slow.
It’s also listed in the documentation.
The simplest way is something like
Does that count as a rickroll btw?
Nah; it wasn’t audible.