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.

Thank you for your generous help and mentorship, Pali. I have submitted your suggested V2.

Thanks! So I tried the compilation, and the check added to the beginning of yours matches the first three instructions of the while( do ... while ) : test3: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. .L15: ldrb r3, [r0] @ zero_extendqisi2 cmp r3, #0 bxeq lr .L16: mov r3, r0 ldrb r2, [r0, #1]! @ zero_extendqisi2 cmp r2, #0 bne .L16 add r0, r3, #2 b .L15 Dang, that's tight! Only 9 instructions with the initial check, because it appears ARM64 has a "pre-index" addressing mode that updates the base register as part of the load. If I understand, that's able to replace the "add" from your loop. But looking at this, it strikes me that the code could be manually adjusted to not need the "mov" instruction. Of course, I have no idea if there are rules on branching before/after a load. ldrb r2, [r0] @ zero_extendqisi2 .L15: cmp r2, #0 bxeq lr .L16: ldrb r2, [r0, #1]! @ zero_extendqisi2 cmp r2, #0 bne .L16 ldrb r2, [r0, #1]! @ zero_extendqisi2 b .L15 But we're awfully far afield of bugfixing, we're into pre-mature optimization. I did enjoy the exercise. You've convinced me about the null byte. It doesn't harm, it would have helped catch the present bug, it has value in the future based on the change you mentioned to memory init. If I'm reworking the patch to include the terminating byte (which is entirely your code, if you're okay with me claiming it), I'll also use the tighter loop, and let the list and CC's provide the comments directly. It may take me a few days to once again cut the patch and communicate the changes.

I am opposed. Let's discuss why. And I recognize that you have more experience here, so I appreciate if you explain your thinking so I can refine my understanding of what is important. Looking at the final null byte, I believe it's entirely superfluous. The entire region has already been nulled out with enough space to hold more than the strings we're writing. If, somehow, the fdtfile variable has begun stomping over other data, it would be better to discover the error by NOT nulling the beginning of the next variable location, as the logic that would read that data would make it visible that there is a problem. Looking back at what we've learned, the lack of "soc", "board", etc. variables should have told us something, but we didn't know what we didn't know. I have no desire to submit that as a patch. As for the "optimized" check for variables against the use of strlen, 9 bytes vs 14, but how long do you have to stare at the optimized version vs. immediately understanding the correctness of the algorithm. Plus, when you add the initial condition check, you may have a few more instructions. The loop itself from .L7 to the end is only 9 instructions. Uh, I don't know how to get the assembly as you did, to compare my optimized version. Do you think it's better to save the bytes at the cost of developer cognition?

That later version (which I sent to the u-boot list, did you see it) was for readability. The code I proposed for size/speed was while (*ptr != '\0') { do { ptr++; } while (*ptr != '\0') ; ptr++; } There is an error in your code. if the environment is empty, you will increment and write new variables. These variables will not be able to be found, as the check for the beginning of the variables will always see the first null byte.

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