ManoftheSea

As far as I can tell, you've booted. OPNsense is running and unable to find the disk. I don't know anything about BSDs, or what driver you might need to find the SATA device on the espressobin. ahci0: <AHCI SATA controller> mem 0xe0000-0xe0177 irq 27 on simplebus1 This looks like it detected the controller. So yeah, I don't know why it didn't find the disk, but the problem appears to me to be the domain of freebsd, not of the bootloader firmware.

br* is a bridge interface. The systemd configuration files have it set up so that all three ports are part of a single bridge. When you unmasked systemd-networkd, it probably got stuck at "waiting for network to be online", which has something like a 3 minute timeout. As you mentioned, systemd-networkd is masked by default, which is normal for every other armbian board. Switching to use Network Manager is a valid solution.

Guys, are you familiar with systemd-networkd? /etc/network/interfaces is not how it's done anymore. Try checking the results of "nmcli"/"nmtui" or "networkctl" to see what is managing the interfaces, and then interact with those systems. I'm not so familiar with NetworkManager, but systemd-networkd keeps its files in /etc/systemd/network/.

I switched to NixOS back in December, and so far have not been able to complete compiling u-boot on that system with any toolchain. The TF-A code needs to get into marvell git repos instead of just gathering binaries, it's not very clean. As such, I don't have any update on the issue either.

@Pali Hi! I've run into this issue. I've got an ebin-v5 with cpu frequency stepping, and an ebin-v7 without, both on 5.15.86. Based on the CPU markings, the v7 is using platform firmware set for 1200 MHz. I'd be interested in seeing what ysou know, but claim no special skill. Likely, I'll just drop the u-boot config back to 1000 MHz even on the v7, if that solves it.

In jammy, it's part of the systemd package, not broken out. In 22.10 and debian unstable, it's broken out to the systemd-boot package. If you keep your kernel at /boot/vmlinuz-6.0.0-6-amd64, then you instead run "kernel-install myKernel /boot/vmlinuz-6.0.0-6-amd64". At least one thought is going to be required to take manual control of installing non-standard kernels.

I was able to boot from a SATA disk that was manually setup with a GPT-formatted table and a debootstrap'ed debian arm64 kernel. The GPT partitions included: 1. BIOS from sector 34-2047, no filesystem 2. ESP from 2048-409599 (which u-boot calls bootable even if the flag isn't set), vfat filesystem 3. XBOOTLDR from 409600-819199 with bootable flag set (0x4), ext4 FS without journal 4. linux swap 5. ARM64 root (gdisk type 8305) with bit 60 set (read-only), ext4 without journal 6. linux /var (gdisk type 8310), ext4, with /srv/ and /home/ bind-mounted from /var/local/ The bootscripts/extlinux configuration live in /boot, onto which is mounted partition 3 (XBOOTLDR) next to the actual kernel/initramdisk. It is necessary to mark this partition bootable in gdisk to have the u-boot distro-boot search it for extlinux/boot.scr. While the espressobin doesn't require u-boot flashed on the boot media, this disk partition scheme would allow rockchip64 systems to boot if the BIOS partition is extended to somewhere around sector 32767 (as rockchip needs code at sector 64 and maybe 16384 and 24576).