They’re all AHCI adapters, I would say though that ASM1164/66 by far works best though.
Shameful thing happened. I should have done something about it from the start. My old router, the Pi 3 has been powered on for no reason, just because I might need something from it. It barely sips power and the SD is not written to, because it is running Alpine.
The problem with that is that I did not disable my scripts to launch my VPN and all other stuff. Meaning that the past 2 or 3 weeks or so of suffering on the wireguard VPN, I could have avoided. I thought initially that my VPN was down, or pfsense went batsh*t crazy again after an update or something. But no, it was just my other router connecting to it using the same certificates and credentials, because I am absolutely retarded.
I continued my zfs-send data transfer, 1.45 TB to go. Now even if my Pi 3 reboots unexpectedly or something, I disabled its @reboot crontab to launch the vpn. Now it is all dedicated to the new router, the rkpr64. Thank lord.
And it’s funny, because I tried my VPN on my phone too, getting the same problem. No wonder.
Unrelated to ARM SBCs, my network on the other side of the pond just became a bit smaller. I took the HP ProCurve 2910al out. I only have my pfsense box, my AP connected to it (just an old router connected to the LAN side with dhcp disabled), my last standing proxmox box connected to trusted and untrusted networks and that’s about it. No other devices, besides my ISPs ONT / router AIO combo which makes my life miserable, is plugged in. Well, there weren’t any other devices for a long time, just that now the switch was taken out, because it was doing nothing and was just loud and obnoxious.
Hehe I feel stupid too. I’ve bought my second rockpro64 with the same kit and was going to use with the sata card I bought that is the same model that works on my first one. I also bought the same sd card. After all I’m vaccinated against all the happy fun stuff that comes with Pine products right?
Well… it didn’t worked. No video. Leds were up but no video was showing. Tried different combinations of power supply. Bought more SD cards with different models and manufacturers. Nada. So I’ve requested an RMA.
Now that I’ve secured an RMA I started trying different things. I noticed the board does work and gets an IP address so the problem must be video right? Maybe flashing the SPI. So I connected the board again to use an unattended SPI flasher available from ayufans’ repo but this time video worked! What happened? I couldn’t care less about what happens to the board this time so I was a bit more rough with the connections. The HDMI connector was just a bit stuck and maybe bent.
1 Like
I’ve got bitten by software support yet again. This time I ordered some eMMC modules, because why would you want to run things from a SD card? Well, guess what? The linux kernel does not have support for emmc booting out of the box. I spent the past few hours trying to get the rockpro64 to boot off of emmc by flashing images to it, before I found out that it is something with the kernel itself.
Supposedly kernels 4.x would work, but not 5.x and up, which is unexpected to say the least. I did order an emmc for the n2+, but now I have a bad feeling about it too. I was hoping that maybe I could salvage it by doing what I do with the Pi 4, to boot from a 2GB sd card and have the rootfs on emmc, but if it’s a kernel thing, it ain’t gonna fly. The official (actual) debian installer for the rkpr64 worked when I boot off of emmc (but I assume it was a modloop or something, because the emmc had nothing mounted, everything was tmpfs). The actual installed system, nor Armbian Buster (5.15) boot though. First is complaining about UUID not being discovered, giving a hint about rootwait (which is enabled in u-boot), the second one doesn’t even boot or output anything. Armbian sid (5.19) did boot, but complained about UUID too.
But this was supposedly a problem since 2020. It is 2022, I tried doing a trick that I read somewhere (and on the crash to initramfs) about adding rootdelay to armbianEnv.txt, but that didn’t work out.
The only way I could maybe salvage it is by running Alpine, which I never got working, but I guess there’s always a start. Or if I could make Void run from tmpfs, which, compared to Alpine, is a bit on the heavy side (it is a full fledged linux distro after all, unlike alpine which is supposed to be small). But I got the 2GB rkpr64, because this is a router build, it basically does nothing, using 133MB of RAM right now. Or I might just give up and run everything from SD cards if it really ends up being that hard to get anything working.
That sucks, not sure if it helps but FreeBSD supports eMMC ootb afaik 
Was planning to run FreeBSD on the other board to use as a NAS. But this one is going to be my router. We already know WiFi is not going to work on BSD. And here I was hoping that with emmc things will just work and won’t have to worry about SDs dying on me.
I tried to get alpine to work yesterday, but failed. Alpine is the only distro I don’t mind running on SD, because it just runs from RAM and writes so rarely on sd. I might try that, with all the failures I got with emmc.
1 Like
USB wifi works very poorly even on Linux unfortunately unless you’re planning to use the PCIe slot for wifi.
1 Like
PCI-E will be some kind of intel 2.5 gbps dual NIC.
1 Like
The system halts in about 10-15 seconds, which ain’t shabby. Booting up is about 120 secs, give or take, which is slow compared to what I’m used to, but it’s gonna be a NAS, so rebooting that won’t happen often.
Thankfully setting this puppy up should be easier than setting the router. I still want to do some funky vlan setup on it (management and internet access vlan + local storage LAN), so I will have to look into that, but shouldn’t be too hard. I am so glad FreeBSD works on this. In absence of it and if I managed to get void to work from emmc, building zfs on it should have been easy after I found what the issue was with dkms. But it sure is nice to have zfs as a first class citizen.
The ASMedia SATA adapter I got also got detected, I plugged 2 SSDs in it, they also showed up just fine as ada0 and ada1. At least the NAS project can move forward. Unfortunately I can’t make it operational just yet. I need the rkpr64 2GB to try and get any linux to boot from emmc (I will give up after a few days probably). Once I get linux on another emmc (I bought 3, 2 for the rocks, 1 for the n2+, which I’m pretty sure should work on the later just fine). I marked the FreeBSD eMMC with a tiny bit of scotch tape, so I know which one is which (I got 2 sandisks and 1 official hardkernel green dot for android on n2+, although I’m not going to use Android, just an easy way to differentiate).
I am so glad to finally see some of my ARM projects just work out of the box.
For the NAS, I will be using 2x 10TB Ironwolfs and 2x 2TB MX500s, all 4 in 2x ZFS mirrors. The mx’es are running btrfs from a previous test on the HC4, will wipe them clean. The ironwolfs are in my TR system, zfs-receiving data for a while. Hopefully the transplant will go smooth (I see no reason why not, both FreeBSD and Linux use the same ZOL codebase now).
And for anyone wondering, I bought a 19V 7A (about 133W) power adapter, which is absolutely overkill and that thing is literally half the size of a brick, it probably is around 30% of the official pine64 rockpro64 case by volume. HUGE (that’s what she said). And to accompany that, I have a stepdown converter (looks like a buck converter, could be, no idea what this thing is, all I know is that it does 5-30v input supposedly just down, but to 5-30v… mkay).
The only thing I don’t like about the converter is that the terminals are on each end, making diying a case for it a bit difficult. I would have loved to have everything on one end, would make cutting the panels easier (just have to cut 3 sides, instead of 4, 2 are for heatsinks). I already wonder how to make the terminals stay in securely. This thing shouldn’t go anywhere, but I’d rather not have stuff randomly disconnect from an accidental fall and “bungee” on its own cables. I don’t trust screw-in terminals, I will probably hot-glue the cables to the case or the PCB underneath (or both). Was thinking of hot-gluing 2 zip-ties and a detachable strap as some kind of cable holder. Maybe I am overthinking stuff, I will have to see if I can just fit this thing in the rkpr64 case and call it a day.
1 Like
Ok, just like on PC you update to the latest UEFI, on ARM boards, you shouldn’t trust that you don’t have some form of ancient revision of u-boot. I got the ayufan u-boot image I had around since September 3 and flashed it to the board. Did not reflash the emmc, just plugged it back in once the flashing was done (which I didn’t know when that would have been, I had a black screen and a red LED light with blinking white LED activity, so I just waited for a few good minutes).
Booted Armbian just fine now. Will delete it and copy my current rootfs from void (it should basically be the same image I’m using on the SD, so thankfully I don’t have to mess with fstab and UUIDs, it should just work - hope I don’t jinx it).
1 Like
The red LED light always on on bootup was a bit worrisome. I remembered that flashing the SPI should have had a screen output. So I looked online and there it was, pin 23 and 25. How could I forget that? Probably my brain did not want to remember me using a screwdriver to very carefully short those pins without touching any other ones. This time I had a jumper cable.
I probably borked my u-boot when I tried flashing the ayufan image. Which may have been a good thing, at least I know this thing is capable of booting from emmc. So I got the SPI eraser instead. Wiped it clean just to be sure. Plugged emmc to see if it boot… fails to initramfs again, lmao.
Unplugged everything, got the latest ayufan image (the one I had seems to have either been created in 2021.07 or 2022.07), which is 2022.10, flashed it to a 2GB SD, plugged it in, jumped the pins, powered on the board, flashed the image… red LED shows up again, this time both LEDs are constantly on. Nothing happens. Fine then, unplug everything yet again, flash the old image I had.
Huh, so it does seem like this image I have, managed to write itself to the board without holding the pins. I saw the white LED blinking once per second, as in the instructions I read, unlike last time when they were both always on. And no video output again either. I let it sit there for a while again.
And it flipping works. I don’t understand, but whatever, I’m happy.
I checked the UUID and they are different. I forgot I downloaded Armbian 22.08.1 with linux 5.15.63 and the previous one was 21.08.1 bullseye 5.10.60. Well, it shouldn’t be too big of a deal.
1 Like
Linux distros and u-boot seems like a mess, just use u-boot upstream :-/
I needed to use FreeBSD’s to make LibreELEC boot at all on my 1G RAM board…
2 Likes
Found my problem. But first, initially I tried my oldest trick in the book, boot from SD and mount the rootfs on another device. I used one of my wonky 2GB SD cards and wrote the first 32k sectors to it, then deleted the first partition and created a new one, then unplugged the sd, plugged the emmc, changed the disk identifier (both were flashed with the same .img file, so they had the same id), then plugged both to the board. To my surprise, it did boot, but with some minor issues that I actually figured out later (the 5.18.19 kernel I had was lacking the modules folder, because I uninstalled it at some point and used kernel 6.0.1).
It was weird that LEDs were turning on at all on the board. So what did I think, if the SD I know boots on the other board boots here, then there’s something wrong with what I’m doing with the images. And to my surprise, the sd wouldn’t boot on the 2GB board. Holy slap!
I didn’t know exactly what I had done before to make it work on the 4GB board, but I knew it involved tow-boot in the process. So I tried messing with it. I know I used the ayufan spi eraser yesterday, so I thought it did erase the spi, but nope, the LEDs were still blinking. I booted tow-boot, installed it, then tried booting the working sd and it still gave me the generic failures that it extracted (or uncompressed or expanded or something) the fdt then getting hung. So I went again to my tow-boot sd and erased the SPI. To my non-surprise, the sd card booted.
I unplugged it, plugged the 2GB sd and emmc, it also booted, but with errors. I copied the old modules folder and the vmlinuz and dtbs to the emmc, removed the 2gb sd and the board booted with 5.18.19 from emmc without issues.
It was u-boot on spi all along. I seriously hate when that happens. Now I am successfully booted into the 2GB board.
__.;=====;.__ oddmin@rkpr64r
_.=+==++=++=+=+===;. ------------------
-=+++=+===+=+=+++++=_ OS: Void Linux aarch64
. -=:`` `--==+=++==. Host: Pine64 RockPro64 v2.1
_vi, ` --+=++++: Kernel: 5.18.19_1
.uvnvi. _._ -==+==+. Uptime: 26 mins
.vvnvnI` .;==|==;. :|=||=|. Packages: 192 (xbps-query)
+QmQQmpvvnv; _yYsyQQWUUQQQm #QmQ#:QQQWUV$QQm. Shell: oksh v5.2.14 99/07/13.2
-QQWQWpvvowZ?.wQQQE==<QWWQ/QWQW.QQWW(: jQWQE Resolution: 1920x1080
-$QQQQmmU' jQQQ@+=<QWQQ)mQQQ.mQQQC+;jWQQ@' Terminal: /dev/pts/0
-$WQ8YnI: QWQQwgQQWV`mWQQ.jQWQQgyyWW@! CPU: (6) @ 1.416GHz
-1vvnvv. `~+++` ++|+++ Memory: 137MiB / 1975MiB
+vnvnnv, `-|===
+vnvnvns. . :=-
-Invnvvnsi..___..=sv=. `
+Invnvnvnnnnnnnnvvnn;.
~|Invnvnvvnvvvnnv}+`
-~|{*l}*|~
2 Likes
I got a nice file server running. The SD card contains a base Linux system with LXC and the network bridges. The encrypted BTRFS raid of SATA SSDs mount at /var/lib/lxc after running a script.
If I ever get tired or fed with the RockPro64 I can buy another ARM64 product and basically run my infrastructure from the SATA drives.
I got a file server with elasticsearch and fscrawler for spotlight indexing. Did you know samba can integrate with elasticsearch out of the box? I’ve been running those 2 java behemoths to behave with as little as ram as possible. I also added scrapers for my roms. Program is lightweight tho. I got this new hobby now which is indexing data.
2 Likes
All heil container migration! Really makes changing hardware (or even host OS) such an easy task. I will be using the N2+ with LXD and containers will be ran on the RockPro64 NAS on the SSD array. I will report back with results when I’ll have them set up, I still need to get the N2+ to bootup fine. Besides, the RockPro64 official case is such a royal PITA to deal with, I need a 12V barrel jack to SATA and a few other things to get the NAS going.
2 Likes
I’ve been thinking it would be great to use a mini-itx case that has a CD-ROM bay where I can put one of those ice docks SATA enclosures. Mounting the board is not impossible since you just need to drill holes or add a custom piece of metal or plastic. The problem is that I haven’t seen an ATX power supply breaker that doesn’t look like a potential house fire.
Speaking of Odroids and cases… I had no idea there was a proper alternative to the ugly transparent toaster. If I knew it before hand I would consider it instead of the RP64.
2 Likes
The PicoPSUs are pretty good, but I don’t know how you split them to 12V, besides just sing the 24 pin connector and connecting it to the RockPro64 via a 5.5 / 2.1mm barrel jack, and jumping the PSU pins to have the PSU always on.
I would rather use a 19v with a stepdown converter, which is what I have now.
There is an alternative to the lovely toaster? Besides making your own? Interesting. Well, I still like my toaster, the only issue is that I could not get ZFS on it yet. BTRFS was running fine, but given that most stuff here will be ZFS, I want to keep things consistent, which is why I was forced to buy another rkpr64 for now. Eventually the toaster will be just an on-demand backup server.
1 Like
Aesthetics aside the way the disks dangle vertically on that plastic case is definitely not a good thing.
1 Like
I have hit a brick wall with the amount of BS I have to deal with with the RockPro64 and official case.
The cables are putting a lot of strain on the SSDs’ connectors if you are not careful. Then you can only supposedly power 2 drives using the included power cable that connects to the rkpr64. Well, stupid me because I didn’t research it more thoroughly. I am supposed to get a 12v brick and a step-down converter to get 5v and add these to the SATA cables myself. The worst part? I have a 19v that I need to lower to 12v, so I need yet another step-down converter to get 5v.
Wow, I can’t believe the amount of BS I have to go through with this. Better be worth it to put an 80mm Noctua fan on this thing, it will run at 100% all the time (2 pins only, 12v and GND), so I need to get the lower RPM ones.
The HC4 has all you need built-in. And comes with a 15v brick and the board does all the voltage step-downs for you. But no support for 4 drives obviously. But support is not explicit for the RockPro64 either.
2 Likes
There are printable miniITX-adapters available for a “regular case”.
1 Like