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.

How will systemd-boot guess the thoughts of users? Users will tell systemd-boot. As I said, you can use bootctl to select the next boot. Usually, the desired kernel is "the latest". But if you have an opinion, go ahead and type it in to the computer, over SSH or console or whatever. "I don't want to play nice with others" - Well, I can't help you there, but being interoperable with the best solution sounds like it's beneficial enough just for our own use, and the interoperability is a side benefit. "User must manually configure" - you're kidding, right? These configuration files are automatically generated and drop into the standard place. It's easier on ourselves, not harder. "Simple instructions" - apt install linux-image systemd-boot; kernel-install Balbes-ornery /usr/lib/linux/linux-6.1-balbes150 /usr/lib/linux/initrd; bootctl set-default Balbes-ornery

What is a "system" or "core" as you use the words? systemd-boot can select next-boot from a running linux system, no monitor/USB needed. GRUB does terrible at detecting other distributions. systemd-boot is simple, a single app on ESP and some standardized config files. How can you claim it's complex without identifying GRUB as more so? It is supported fine in any new enough distro.

@IgorI'm sorry I missed this ping. Extlinux is nice enough, but keeps all of the configuration within a single file, which makes it difficult to manage a multi-boot setup. GRUB is a long known bootloader, but it's full of so much legacy - I don't know anything it does better than another option, and plenty it does worse. It does have an advantage of drop-in include files, but it also likes to repeat itself over and over and over again. systemd-boot is nice and clean, but doesn't have support in Debian Stable.

@ABF023It's not supported by armbian (yet?) but: If you put a UEFI application on an ESP on a GPT-partitioned disk in the right location, u-boot will boot it. And I think u-boot (2023.01-rc4, at least) will pass an internally saved DTB to the UEFI app. So you need to partition your disk as GPT, add a vfat filesystem with UEFI parttype (EF00 in gdisk), and put either the kernel or systemd-boot at EFI\BOOT\BOOTAA64.EFI (which systemd-boot will handle). This is possible in latest Ubuntu and Debian Unstable.

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).