There’s not need for the eMMC module unless you’re going to hammer the filesystem 
2 Likes
I mean, I could use a SD card, for sure, but I don’t really trust those anymore. I’d rather get a small eMMC and just run off of that, for my peace of mind.
2 Likes
Sure, I’ve had very good experience with the following in my Rockchip and Allwiinner systems
The older ones and Amlogic runs slower Toshiba (now Kioxia) simply because everything is loaded into memory (they run LibreELEC or CoreElec) and due to compatibility concerns
These are however noticable slower than the A1 rated cards listed above (A2 rated seems to be 64Gb or more)
3 Likes
NFS seems awfully slower than an SD card. Like, extremely slow. I’ve been unpacking a linux kernel header for more than an hour now. It looks like it’s stuck. I ctrl+c out of it and tried restarting it. The same issue, now with the unpacking from the start again.
Dmesg doesn’t report any issue. But the NFS server seems to be slow. Takes like 10 seconds to do an ls in /var/service, which is just a bunch of symlinks.
bikyhc4# dd if=/dev/zero of=/root/papapa bs=1G count=1 oflag=dsync
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 217.184 s, 4.9 MB/s
bikyhc4# dd if=/dev/zero of=/root/papapa bs=512 count=1000 oflag=dsync
1000+0 records in
1000+0 records out
512000 bytes (512 kB, 500 KiB) copied, 4.63013 s, 111 kB/s
bikyhc4# dd if=/dev/zero of=/root/papapa bs=512 count=1000 conv=fdatasync
1000+0 records in
1000+0 records out
512000 bytes (512 kB, 500 KiB) copied, 0.0627341 s, 8.2 MB/s
bikyhc4# dd if=/dev/zero of=/root/papapa bs=1M count=256 conv=fdatasync
256+0 records in
256+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 24.779 s, 10.8 MB/s
bikyhc4# dd if=/dev/zero of=/root/papapa bs=8k count=10k conv=fdatasync oflag=dsync
10240+0 records in
10240+0 records out
83886080 bytes (84 MB, 80 MiB) copied, 745.087 s, 113 kB/s
bikyhc4# dd if=/dev/zero of=/root/papapa bs=8k count=10k conv=fdatasync
10240+0 records in
10240+0 records out
83886080 bytes (84 MB, 80 MiB) copied, 28.2648 s, 3.0 MB/s
bikyhc4# dd if=/dev/zero of=/root/papapa bs=8k count=10k oflag=dsync
^C1740+0 records in
1740+0 records out
14254080 bytes (14 MB, 14 MiB) copied, 594.892 s, 24.0 kB/s
It seems like on many small files, this thing takes ages to finish. 12 minutes to write 80MB, that’s insane. When writing a 256x 1MB files are written in 25s and one 1GB file is written in 3 minutes or so. Maybe I don’t understand the flags properly. Combining them seems to have very bad results. fdatasync works fast, but dsync is the one that doesn’t seem to cache the entries. As of now, it’s still writing. I ctrl+c out of it, attached above.
And again, I’ve waited more than 1 hour for it to extract a kernel header via the package manager. Now I’m just performing a removal, as I don’t need the kernel, as I have the one from the official Ubuntu image, but even deleting files is slow.
1 Like
On the HC4, I can’t figure out how to boot a mainline kernel. Done similar things to how the official Ubuntu image is done (which is weird to begin with): gzipped vmlinux, u-boot uInitrd, dtb and the usual boot arguments. With the 4.9 kernel from Ubuntu, it works. The same with 5.15 does not. The dtb is meson-sm1-odroid-hc4.dtb, which is not the same as the meson64_odroidhc4.dtb from 4.9.
I tried other combinations, like building a u-boot image and a uInitrd, but to no avail. Also, loading the normal, uncompressed vmlinux and initrd or initramfs fails too.
I need to check if kernel 5.10 was working on the HC4. I know that on the n2+ I used debian’s 5.10-meson, then upgraded to mainline 5.15 and works, but I can’t seem to replicate my success on the HC4. I hope I can nail it with any kernel.
2 Likes
Man, is troubleshooting so much easier when running off of netboot. Not having to get up, power off the SBC, unplug the SD, plug the SD into my reader, then into my Pi, sit, mount SD, modify stuff, unmount, get up, unplug, plug, then power up and rinse and repeat.
Now it’s as smooth as reboot, fails to boot, modify the pxelinux.cfg, get up, unplug and plug the board the board, sit. Just so much more enjoyable.
Edit: spell checking.
2 Likes
DOT COM
The quartz64 is an interesting board. It has 4x PCI-E 3.0 and 3x PCI-E 2.0 if I recall correctly. It is technically compatible with more pci-e devices, hopefully even the official Pine64 sata hba, which is not compatible with the rockpro64 for some reason.
But it’s a fresh board, it has virtually no support. I don’t want to imagine the pain I’d have to go through to get this to boot anything other than official images. I’m willing to get a VIM4, because of the specs, but the only reason I didn’t buy one now is because the only thing I hate more than Amazon is PayPal. And ameridroid still doesn’t have them in stock after more than 3 months since its release
And it’s crazy, those guys have the VIM3 and the Quartz64 model A, but not the VIM4. From what I understand, the guys at Khadas don’t want to let them buy stock or something. Ameridroid even have for the Rock5 model B. The Rock5 from Radxa has the same RK3588, up to 16GB of RAM, wifi 6e, 2x m.2 slots, triple monitor support and 2.5Gbps Ethernet with PoE support. The quartz64 is cheaper though.
I’m currently very tempted to go back to x86 and grab a NUC or an USFF 6 core Ryzen box, or if I’m crazy enough, a Honeycomb LX2K SFF build. I’m tired of the Pi 4 as a daily driver. It has its perks, but the bugs this board has are nuts. The reason I wanted something like a Pi was because I could power it from USB, but seems like I never really made use of that (probably because I have a metal enclosure, so wifi does not work). Still, I want to have that option and the only boards that I could use for that are the Khadas VIM4 and Rock Pi 4 or Rock5. Neither of which are supported by mainline Linux yet.
The Odroid H2+ (Celeron J4115 quad core) seems good both as a desktop and as a x86 router. It has 2x 2.5Gbps Ethernet… I don’t need more power than the Pi 4 has for daily activities, but the display not getting detected after turning off or unplugging and the USB devices going nuts is something that seems pretty small, but has become very annoying.
Back to the HC4, yesterday I tried getting 5.10, 5.15, 5.16 and 5.18, none of which worked. Well, 5.10 didn’t even have the dtb for the hc4, only for the c4, so I wasn’t expecting it to work. From what I understand, dtbs are losslessly decompilable into dts’es, so maybe I could decompile the mseon64_odroidhc4.dtb into something that a mainline kernel could read?
The problem I’m having is that after petitboot goes into kexec, the board does nothing afterwards, there is no storage activity LED going on. So I am completely puzzled as to what I could do to mitigate this. Dual-booting might be an option if I want updated kernels. Debian has a meson kernel IIRC, so I could boot into debian, update the kernel, then boot back into Void with updated kernel. But that’s bollocks. Also, the Armbian build of zfs-dkms lacked some makefiles for aarch64. Which is beyond ridiculous. Yes, I did try to install zfs-dkms, although it was on the N2+ on 5.10, but it didn’t work, so I gave up.
Maybe dual-booting Gentoo and compiling the kernel with everything needed and not requiring a dtb might be an option. At this point, the project has been stalled for a long time due to lack of ZFS support in the kernel. I do have BTRFS support and I would only be using a mirror, but I would prefer sticking to what I know works and allowing other people to test it. I wouldn’t mind btrfs on Fedora or Tumbleweed on a single disk if I’d be using them, but not on my NAS.
For now, I should definitely start working on getting the N2+ back up and running. At least this shouldn’t need fancy things that can’t be found in the kernel. And last time I got it to run on 5.15. Now I need to get it to boot from netboot and mount root on NFS… on U-Boot… big OOF.
Ok. I’m dumb. I’ve read a little. I knew that the n2/+ were supposed to come with petitboot preinstalled. But I never saw it boot up with that. It always needed U-Boot on the microSD card to boot. I was aware that the N2+ had a SPI / MMC toggle. I thought “maybe my petitboot is corrupt or something” or rather “maybe my petitboot is old and it doesn’t have the correct parameters to output to a display”. Oh, couldn’t I have been so wrong.
I looked up on how to recover it. Supposedly I had to write an image to an SD using Balena Etcher. From my previous experience, I didn’t want to do it on Linux and I didn’t feel like starting up my tablet. But I kept on reading. “*6. Toggle the boot mode switch to SPI boot mode”.
And then I realized… “IT CAN’T BE!” I took my case off… and there it was. The board was set to MMC.
But given that I already downloaded 3 files (2 updates and 1 recovery, because I thought maybe I could be running petitboot and I only had to put the updater image on the SD), I decided to upgrade it anyway. Hardkernel does not recommend upgrading petitboot if you don’t have any issues with it. I was on 20211112 and I upgraded to 20220317. But the upgrade didn’t go by itself, I had to go to the shell and do a pb-update. So the install wouldn’t have gone by itself anyway if I were to just plug it in.
Now I can more easily test images. Thank Lord. The more curious question would be if I could use the dtb from the debian 5.10 meson kernel on the mainline 5.10 kernel. I’ll have to test it. Oh man, I’m so glad I don’t have to flash SD cards anymore. Now all I have to do is figure out how the RockPro64 does stuff… Boy am I glad to be running petitboot on both the n2+ and the hc4. I kinda like it more than U-Boot. I doubt it can boot into OpenBSD, but supposedly kexec can launch FreeBSD.
How the hell did I make 5.15 to work on the n2+?
1 Like
Quartz64 isn’t a replacement for the RockPro64, it’s rather a replacement for Rock64 (PCIe slot and more memory essentially). While there is support in mainline Linux you really need to run bleeding edge and there aren’t drivers yet for all components but its slowly getting there.
Given my absolutely failed attempts of getting any system that would have ZFS module build into the kernel to boot up on the Odroid-HC4, I decided that I would be getting into NixOS. The rabbit hole is deep on this one. Probably not the best place to start my journey into NixOS, especially not on netbooted and nfs root images… Hopefully I don’t give up too fast on this one.
I am thinking that, at least with a source-based distro like NixOS, there shouldn’t be a problem with building the ZFS module into the kernel, like I found myself on Debian, Ubuntu and Void. If FreeBSD had Odroid HC4 support, I would have probably used it, as ZFS is a first-class citizen there. Even though getting into BSDs would be an even deeper rabbit hole for me to jump into, because at least I am familiar with the boot process on Linux. BSDs on the other hand? Besides the fact that they can boot from u-boot or via netboot, I have 0 clue on how I would even get it to work. But BSDs have their fantastic documentation going for them, unlike many Linux distros.
But what NixOS has a big advantage in its favor is the ability to recover from an empty /, as long as /boot and /nix exist, which is insane to me and I kinda want to test that out. It would be even crazier than Alpine diskless install, as at least Alpine backs some of its files up via lbu commit. This thing doesn’t back anything, it has system states stored under /nix/store and it can basically symlink-foo into a working state without following the classic FHS.
1 Like
Just found out that booting NixOS ain’t too different from booting anything else on arm sbcs. You got a typical extlinux.conf setup that easily translates to a pxelinux.cfg file. Just need to add my own options, like the NFS root and other boot parameters and I should be good.
Now that I think about it, booting FreeBSD would have probably been the same, but since it is very likely it would not have dtbs for the hc4, I don’t think I can make it work. All dtbs seem to be different from kernel to kernel for some reason.
file amlogic/meson64_odroidhc4.dtb
amlogic/meson64_odroidhc4.dtb: Device Tree Blob version 17, size=72700, boot CPU=0, string block size=7668, DT structure block size=64976
file dtbs/dtbs-5.16.20_1/amlogic/meson-sm1-odroid-hc4.dtb
dtbs/dtbs-5.16.20_1/amlogic/meson-sm1-odroid-hc4.dtb: Device Tree Blob version 17, size=49319, boot CPU=0, string block size=2251, DT structure block size=47012
file dtbs/dtbs-5.18.11_1/amlogic/meson-sm1-odroid-hc4.dtb
dtbs/dtbs-5.18.11_1/amlogic/meson-sm1-odroid-hc4.dtb: Device Tree Blob version 17, size=50256, boot CPU=0, string block size=2264, DT structure block size=47936
This is the most weird thing I’ve ever seen in trying to boot stuff on any SBCs. The storage activity LED is blinking, indicating that something is happening. It’s blinking at a constant rate though, so it’s most likely an error and retrying a couple of times.
I set the boot parameters properly, but got no display output. The image, dtb and initrd seemed to be downloaded fine. But it is likely that the nixOS init was looking for a physical media, not for a NFS mount. And not having a display output doesn’t debugged easy, or in this case, not even possible. I don’t feel like burning an SD to run it and configure it to boot from NFS just yet. Besides, I deleted the old image, it was using space up, I only have the rootfs extracted.
Was worth a shot. Might look into it at another time.
1 Like
I’d expect Meson support to still be be rather fresh so expect bumps. Regarding ARM in general I’d say unless there’s explicit support for your board/SBC I woudn’t even bother trying.
1 Like
Void doesn’t explicitly have support for hc4, but the kernel does seem to have some support. NixOS explicitly supports the hc4, but not through netboot and from what I can tell, the nixos init configuration uses some kind of /dev/disk/by-label/ hackery. I tried to modify it to NFS, but didn’t work out. FreeBSD doesn’t support it at all, so I won’t bother.
There’s no support for Amlogic SoCs at all in FreeBSD, I’d just use it for CoreELEC and/or possibly Lakka (no idea how well it runs using Lakka) and that’s about it 
Unfortunately some SBCs and SoCs doesn’t get much love in the end…
2 Likes
I’ve been fighting for the past 3 hours with the RockPro64. I have Tow-Boot installed on it, but OpenBSD was always failing to boot. I thought maybe it’s something wrong with OpenBSD. Oh, no. Today I just tried Alpine and Armbian and both of them are failing when trying to load the kernel from a certain address.
I didn’t manage to make Tow-Boot boot from PXE. It looks like it wants a boot.scr as opposed to a typical pxelinux.cfg. And I have no idea how to make a boot.scr with tftp variables.
Anyone knows if u-boot needs to be compiled for each board? Because if so, I’m in slightly shallow 
1 Like
Note: I only tried Armbian and Alpine because I already had them downloaded. Just got FreeBSD 13 for the RockPro64, will try to see if that works.
u-boot is board specific and depending on how the distro/OS boots you may need a new u-boot “binary”. FreeBSD 13.1-RELEASE works just fine.
1 Like