I left for about 1 - 1.5h to cook something and the SD card is still supposedly being written. dd got stuck at 2.4GB out of 3.
It seems I had a device disconnect, the SD card changed from sdb to sdc during write. I have a dumb idea that might actually work, I’ll use my hc4’s sd slot, as it is netbooted and using nfs rootfs, so I can write to the sd directly, as opposed to my usb adapter.
FreeBSD is broken too. So it’s not me going crazy. It got stuck around the same place as Alpine, Armbian and OpenBSD, booting the kernel at whatever address, then here it shows masks 0x00ff00000 and 3 more 0xff0000 stuff. Couldn’t bother to count the Fs and 0s properly.
I wonder if wiping Tow-Boot will get rid of this issue. But then I wonder if I’d be able to boot anything afterwards. Man, I really wish Petitboot was available for the RockPro64, it’d make my life so much easier.
Having multiple uboot may very well cause issues. Your SD card/reader is also borked if it takes 1h+ to write a few Gbytes of raw data.
When I used my hc4 to write to the SD card, it took around a minute or so. dmesg also did not report any I/O errors. The SD seems to be fine.
I wonder if I’d be able to recover the RockPro64 if I wipe the SPI clean, like I did before with the hc4. Probably not the brightest idea to install Tow-Boot on it.
As far as I can tell my SPI flash is clean
Just managed to make Tow-Boot to load the files via tftp. Just to check if there’s anything wrong with my SD card, which I doubted in the first place, but now I can confirm it, after loading the dtb, kernel image and initrd, it gets stuck at “Booting using the fdt blob at 0x1f00000.”
I have no idea how I would wipe the SPI. On the hc4 I did it by bypassing the SPI bootloader by pressing a button on the bottom while booting. The n2+ has a SPI or MMC toggle. I don’t remember the rockpro64 having any of that and it doesn’t look like there’s anything apparent on the board to bypass the SPI.
Reading some posts on the pine64 forum, it seems like the rkpr64 has the boot priority eMMC → SPI → SD Card. I was planning on buying an eMMC drive anyway, but I wonder if I’ll be able to fix my issue.
I wonder what the 2 pins right near the eMMC module do if jumped together. I need to read the rkpr64 wiki.
Jumped pins 23 and 25. Just booted into FreeBSD. Powered the board off, tried doing the same with my OpenBSD SD card. I get a back screen.
I booted back in FreeBSD. And I realized how long it takes to boot. Thank god I’m no going to reboot often. I need to delete the SPI and see if OpenBSD will boot. Otherwise, I’ll stick with FreeBSD, but I’ll need to change the SD card, I’d prefer to keep the 64GB one free.
Long? I just tested it on my board here, about 1m20sec that’s from when I it enter on shutdown -r now until I get a login prompt again. That includes connecting iSCSI drives, utilizing PCIe, starting dhclient(8) synchronously at startup and of course the board init itself.
I’m spoiled by Void Linux, from the moment I power the board, to being able to SSH, it’s like 20 seconds. But again, if I almost never reboot, I can stand a 1m+ startup.
The OpenBSD install71 and miniroot71 don’t boot at all. Seems like those require I flash u-boot at the beginning of the SD. It does come with a u-boot.bin, but I think that’s generic and not built for each sbc. But I do have an idbloader.img, u-boot.itb and u-boot-rockchip.bin, together with the dtb from an OpenBSD x86 VM. I’ll give OpenBSD a bit more testing before I give up and use FreeBSD.
u-boot files are sbc specific and you should have some instructions similar to this in OpenBSD
https://cgit.freebsd.org/ports/tree/sysutils/u-boot-rock-pi-4/pkg-descr
The past couple of days, I tried messing around with the hc4 and trying out arch on it. This thing fails to boot on NFS. Well, technically, the kernel and dtb are loaded, but when it comes to mounting the nfs root, it fails. I mounted the NFS on my pi, chrooted into the rootfs and guess what, arch does not have nfs-utils installed. And when I try to install it, it breaks dependencies on krb5, which for some dumbass reason, is a dependency on curl, openssh and gnome-online-accounts. Besides openssh, I don’t even need all of those other stuff. Libverto and krb5 are in conflict. Thanks, pacman!
I do not understand why some distros use meson64_odroidhc4.dtb, while others use mseon-sm1-odroid-hc4.dtb. And Arch Linux Arm has both of them included in the dtb folder for their kernel, it’s crazy…
meson64_odroidhc4.dtb: Device Tree Blob version 17, size=72700, boot CPU=0, string block size=7668, DT structure block size=64976
meson-sm1-odroid-hc4.dtb: Device Tree Blob version 17, size=49079, boot CPU=0, string block size=2251, DT stru
cture block size=46772
They are basically the same dtb version, but they are always different sizes. I do not understand how dtbs are even supposed to work. It drives me insane.
Because upstreaming takes time and it’s lots (not) of fun maintaining random hacks… Its basically a matter of poor maintenance between Linux distros
> compiled gentoo 4 days on the hc4
> fails to boot
REEEEEEE
Well, in all fairness, I only compiled the kernel on the hc4 for about 8 hours or even less. Then I left nvim to compile overnight another night, then same for a few other things, like dhcpcd, so I could have technically gotten a base installed in a day. But I needed root on NFS and networking support. Not sure what I’m doing wrong.
I also compiled the amlogic support in the kernel when I built it, but it doesn’t seem it caught it. I also given it meson-sm1-odroid-hc4.dtb to use from the gentoo sources, but it doesn’t work. Well, at least it was a good learning experience. Emerge ain’t that hard.
Now, I wonder if I can get FreeBSD on the HC4, with root on NFS. Might be a tough call, especially since FreeBSD does not support the hc4 yet.
There’s no support for Amlogic chipsets in FreeBSD so no need to even bother.
FreeBSD base takes about 7-8h on my RockPro64 with a few things ripped out such as debugging and tests.
Kernel(s) GENERIC-NETWORK built in 1331 seconds, ncpu: 6, make -j6 on my RockPro64 (FreeBSD 13.1-RELEASE)
Despite that, your HC4 sounds awfully slow? Perhaps its stuck at a low cpufreq?
The hc4 is a quad core a53, the rockpro64 is a 6 core big.LITTLE, 4 a53 cores and 2 a72 cores. It is going to compile faster. But even so, compiling the kernel overnight, with a few utilities is not that bad. Besides, the linux kernel is larger than freebsd one. I did strip it of some stuff, like all the other arm support and a few things like kvm/virtualization stuff and hyperthreading support (since the cpu does not have smt). I think it is decent. Besides, the cpu is the slower of the bunch, it goes only up to 1.8ghz, while in other scenarios, it can go to 2 and up.
Yes, the Linux kernel is certainly larger (I added that data for “fun”) but that sounds very slow for 4x A53 cores @ 1.8GHz. Oh well, bummer that it didn’t boot.
I have a new “slightly optimized” build for FreeBSD 13.1-RELEASE-p1 around if you’re interested, the kernel is for RockPro64 but userland also works on Allwinner H5 and H6.
Cool, but I’ll have to pass. Thanks though.