bschnei

No disagreement @Igor. I wouldn't recommend any distro attempt to maintain device-specific support for this family of devices. Especially because there is a pathway to UEFI booting which does allow these devices to be supported by generic kernel packages. I also feel that it shouldn't land on any Linux distribution to be expected to provide support for bootloaders. As a result, I was impressed by the amount of effort I saw around this device and sympathize with how you and the Armbian team must feel.
 
I would, however, caution against letting that frustration spill over into resentment of your user base (or potential user base). I'm not familiar with Armbian's philosophy and what the expectations are between users and maintainers/developers. At Arch Linux the philosophy and expectation is extremely DIY/self-support oriented and those expectations are made very clear. However, that can come across as rude/off-putting to people who show up looking for help. And when you have a volunteer effort (which by definition means you are chronically under-resourced), that kind of philosophy/approach can scare away potential future volunteers/contributors. And obviously if a volunteer project can't attract/retain new contributors then it's just a matter of time before it's dead. Anyone considering Arch Linux ARM for this family of devices would be wise to read this thread: https://bbs.archlinux.org/viewtopic.php?id=290931
 
Personally, I throw most of the blame for the state of these devices on Globalscale and Marvell. The CPU frequency scaling debacle that seems to actually be related to an improperly configured bootloader all along seems to have burnt everyone out so people moved on to other devices. The one silver lining is the open source bootloader. With frequency scaling no longer an issue and UEFI supported, there really is no technical reason these devices can't be supported:
 
ben@ebu-dev:~$ sudo hostnamectl Static hostname: ebu-dev Icon name: computer-embedded Chassis: embedded Operating System: Arch Linux ARM Kernel: Linux 6.9.9-1-a3700 Architecture: arm64 Hardware Vendor: globalscale Hardware Model: Globalscale Marvell ESPRESSOBin Ultra Board Firmware Version: 2024.04-dirty Firmware Date: Mon 2024-04-01 Firmware Age: 3month 2w 3d  
It is, as you correctly note, a question of time/effort.
 
I'm not super familiar with this distribution and community and don't want to step on anyone's toes. If the generic kernel packages provided here are still being configured to support these devices and the only obstacle is how to fix/configure the bootloader, then that's where I am offering to share my experience. But anyone that wants to get Armbian running on their mvebu device is going to have to be willing to put in the work to at least get their hands dirty messing with U-Boot and potentially even building/flashing a more modern bootloader.

Hi all, I came upon a few threads in this forum while working on the bootloader for my ESPRESSObin Ultra. I noticed all of the warnings here about CPU frequency (https://www.armbian.com/espressobin/#), and I think this community might be interested in the work I'm doing.
 
I've have an ESPRESSObin Ultra which ships from Globalscale with old, buggy, and unmaintained firmware. I think the old firmware could explain a lot of the issues users have reported here with the V7. I forked the old factory firmware build script from Globalscale and moved it all to up-to-date, upstream projects: https://github.com/bschnei/ebu-bootloader

I believe with some small modifications, it is possible to also build an up-to-date bootloader for other Globalscale devices that also use the Armada 37XX SoC, for example the ESPRESSObin V7.
 
I currently use Arch Linux ARM on my device and have notified their community as well: https://archlinuxarm.org/forum/viewtopic.php?f=67&t=16746

One of the issues I can confirm has been fixed is EFI booting from U-Boot. Fixing this means we can use U-Boot Standard Boot (bootflow scan) to load user-friendly EFI apps like systemd-boot, GRUB, etc. This significantly streamlines the boot process eliminating the need for u-boot to load separate kernel, initramfs, and device tree files. This also makes packaging it a lot easier too.
 
It also means your bootloader becomes configurable from the OS which is really nice because it means your distro of choice can configure the bootloader instead of requiring users to configure U-Boot manually. I'm not familiar with Armbian, but I think it ships with systemd-boot (?) which has an EFI application that gives you a user friendly way to control device booting. GRUB has a similar capability.
 
Please send me a note if you are interested in testing firmware for the ESPRESSObin V7 or Ultra.