bschnei

Thank you! I'm still in the middle of a long build (chromium). I'll be able to check the flash-image-DDR4-1g_1cs_5-1200_750 image with the specific device I own with frequency scaling enabled and report if it is stable or not. It will crash pretty reliably if the firmware doesn't have the change I submitted here: https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/commit/622677674cf34ef8fdf75b0c580d27efc8628ae8

Thanks @laibsch but, as I noted above, the mirror links there don't work for me. I can only offer to help with bootloader testing here. It's not clear to me how I would build only that component from https://github.com/armbian/build.

OK, where would we find the images that need testing?

Hey @Igor, is there new bootloader firmware built as a result of your changes? I can probably do a quick test at some point (I've got a large build underway on one of my devices). This page is probably in need of work: https://www.armbian.com/espressobin/ the download links don't seem to work for me (they redirect to mirrors.aliyun.com)

@0jay the work I've done on the firmware is here: https://github.com/bschnei/ebu-bootloader. Looks like MOCHAbin is an Marvell Armada 88F7040. I believe with the correct changes to configuration, you can build firmware with my scripts. There is another user here with ESPRESSObin v7 and v5 devices that may try to build firmware using my scripts as well:

To build for other devices, you need to figure out the correct configuration and adjust these values accordingly: https://github.com/bschnei/ebu-bootloader/blob/main/Makefile#L15-L19 Reference for configuration options is here: https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html So for V7 you probably want DDR_TOPOLOGY of 5 or 6 depending on RAM size; for V5 a value of 2. You'll have to look up your defconfig in u-boot. It's probably this one: https://github.com/u-boot/u-boot/blob/master/configs/mvebu_espressobin-88f3720_defconfig but note that I have added an ultra variant here: https://github.com/u-boot/u-boot/blob/master/configs/mvebu_espressobin_ultra-88f3720_defconfig which has settings required to provide HWRNG to the kernel at boot. So you may way want to start with the default if it is known to work and experiment with your own configuration file. You know how to test an image without flashing it to SPINOR, right? I have a guide at my repo above. Regarding Armbian and device support in general, there is another thread here where I had some back and forth a while back:

DVFS has been working well for me on two devices for over a year now. Linux accepted my patch to re-enable 1.2Ghz in 6.15. I build my own Arch packages, but I started with ALARM. I didn't like the way they packaged the kernel and it wasn't being maintained. There are a few of us working on bringing Arch to aarch64. You'll find us on IRC. Libera.chat #archlinux-ports The ALARM project is a completely independent project of Arch Linux (despite the confusing name). I have no issues with random number generation. It was actually fixed by this project: https://gitlab.nic.cz/turris/mox-boot-builder which builds one component of the bootloader. So I use that project (instead of Marvell) for that part of the bootloader.

@0jay I'm sorry I never got a notification for your response here for some reason. I have two ESPRESSObin Ultra devices humming along just fine with no issues, everything working as far as I can tell, no patches to U-Boot or Linux needed. I'm not familiar with the Mochabin. Did you experience issues with it as well out-of-box?

Hi @y52, I've been using the bootloader builds from my repo above on my ESPRESSObin Ultra for quite some time now. Not only do they have up-to-date U-boot, but frequency scaling works perfectly. I'm not very familiar with the V5 and V7 variants, but I think the V7 has the same CPU (possibly different memory). > hostnamectl Static hostname: espressobin-ultra Icon name: computer-embedded Chassis: embedded Machine ID: 2ba0ba22c6164c Boot ID: 514bc8387b7847 Operating System: Arch Linux Kernel: Linux 6.17.3-1-a3700 Architecture: arm64 Hardware Vendor: globalscale Hardware Model: Globalscale Marvell ESPRESSOBin Ultra Board Firmware Version: 2025.10-ge50b1e871501 Firmware Date: Wed 2025-10-01 Firmware Age: 1month

Suggests you don't have the 64-bit ARM cross compiler installed or the location of its executable is not on PATH.

Thanks for the taking the time to provide this additional context! If full device support (i.e. including bootloader) is the goal, that is indeed an ambitious one. I'll do what I can to offer bootloader related support where I can in the forums here, but my advice to everyone is generally going to be to move to UEFI/U-Boot Standard Boot (`bootflow scan`). Some of the U-Boot scripting I've seen to try and support all of the possible combinations of hardware and potential removable storage is just too clunky. When users show up with devices that won't boot, it's a true nightmare to try to support. As a result, any configuration where U-Boot loads additional configuration from a storage device (vs its dedicated SPINOR) is always going to problematic because they vary across devices in the same mvebu family and users may want to change them (e.g. boot partition on USB device vs EMMC or SATA). In short, U-Boot should ideally only chainload a userspace configurable bootloader (systemd-boot, GRUB, etc.) that can be more easily updated/packaged and supported.

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.

@ABF023 while I don't own this device, I do own a variant (ESPRESSObin Ultra). I can't speak for the previous device maintainer (@ManoftheSea), but having spent a lot of time working on the bootloader for my device, I can tell you one of the biggest obstacles this family of devices (Armada 37xx/mvebu) faces with getting any sort of Linux distribution support is that they are shipped from Globalscale with a bootloader that doesn't support modern (UEFI) booting. This is all the more frustrating because upstream U-Boot (the bootloader used by this family of devices) DOES support UEFI. Globalscale's bootloader repositories are open source, but haven't been updated in years. So, as you'll see, I forked their build repo and did a lot of work to bring everything up-to-date which fixes the issue of UEFI not being supported by the factory bootloader. Indeed, you'll note on the device page that "manual flashing to latest u-boot is mandatory" along with a scary note about instability. I announced my work in this forum a while back, but nobody has reached out. While my repo builds firmware specifically for the Ultra variant of the device, it shouldn't be too complicated to modify the scripts and configuration to build for other A37xx variants (assuming upstream U-Boot supports the device). I personally do not have capacity to provide "soup to nuts" support for this device on Armbian, but if anyone were interested in picking up where the previous maintainer left off and wanted help building a modern bootloader that would make supporting this family of devices much easier for any maintainer, then I would be happy to help. EDIT: FYI, I believe this family of devices also gets some support from both Debian and Arch Linux ARM communities. Note that Arch Linux ARM is currently independent of the Arch Linux project, though there are some initial discussions happening around how Arch Linux could provide better support for non-x86 architectures.

Possibly. It looks like Armbian uses symlinks in /boot so it might upgrade just fine. The downside is that symlinks only work on ext4 but not on FAT so if you want to follow the standard spec for EFI boot you need an EFI System Partition (ESP) which is FAT formatted. U-boot probably does not care, but GRUB and/or systemd-boot may throw warnings and/or fail to automatically identify the ESP. I can't be much help with the bootm command--I'm not familiar with that one. But you can try EFI stub booting using bootefi--you do not need to go all the way to Standard Boot and in fact I wouldn't until you confirm EFI booting actually works. The build of u-boot that shipped with my device doesn't have working EFI boot which you'll note is one of the reasons for me building my own bootloader. I have no issues with Armbian and am not loyal to any particular distribution. Arch Linux ARM is not officially Arch Linux and has some serious issues right now. And in any case, the bootloader is distribution agnostic since it is only responsible for getting the device as far as U-Boot...the rest is left up to the distribution. I already announced my work in this forum and over at Arch too, but nobody has reached out so far. Based on the history, I suspect a lot of users got frustrated with some of the problems their mvebu-based devices had and have long ago given up. But if there are users here willing to test bootloader images, I'm happy to help.

Nicely done! Yes, I would encourage you to customize variables and bootcmd to suit your specific purpose and avoid using the confusing and bloated scripts/commands that are often found in the default settings. Yes, you are right, boot.scr overwrites the root kernel parameter. Do you know if you were using UUID before to boot? I've found the /dev names to be stable especially if it's mmc. There is the possibility for problems if you use both USB and SATA drives for example, but unless that is your case I would probably just use the /dev device name. Arch Linux ARM has some much simpler u-boot settings you could probably use/adapt for your situation: https://github.com/archlinuxarm/PKGBUILDs/blob/master/alarm/uboot-espressobin/uEnv.txt By default u-boot runs the value of bootcmd. So for example, a simpler approach like this could work for you: get_images=ext4load mmc 0:1 $kernel_addr_r boot/Image && ext4load mmc 0:1 $fdt_addr_r boot/${fdt_name} get_ramdisk=ext4load mmc 0:1 $initrd_addr boot/uInitrd bootargs=console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/mmcblk0p1 rw rootwait bootcmd=mmc dev 0; if run get_images; then if run get_ramdisk; then booti $kernel_addr_r $initrd_addr $fdt_addr_r; else booti $kernel_addr_r - $fdt_addr_r; fi; fi Saving the values you want (and that you have confirmed work) to permanent storage with saveenv will then bypass boor.scr and armbianEnv.txt entirely. Be warned that this does have tradeoffs though because if Armbian developers decide they want to change the location/name of the kernel (for example) or any of the other values you have coded into a u-boot environment variable then a simple upgrade could mean boot fails again until you go and figure out what was done. Having seen how Arch does things and here how Armbian does things for these devices, my opinion is that both are super clunky. Modern U-Boot supports EFI stub booting so that's the approach I use. The result is: => printenv arch=arm baudrate=115200 board=mvebu_armada-37xx board_name=mvebu_armada-37xx bootcmd=bootflow scan bootdelay=2 cpu=armv8 ethact=ethernet@30000 ethprime=eth0 fdt_addr_r=0x6f00000 fdtcontroladdr=3faf8900 filesize=722 kernel_addr_r=0x7000000 loadaddr=0x6000000 netdev=eth0 pcb_rev=1.2.0 pcb_sn=CPE-2247-000050 ramdisk_addr_r=0xb000000 soc=mvebu stderr=serial@12000 stdin=serial@12000 stdout=serial@12000 vendor=Marvell and then I can use systemd-boot (or GRUB or whatever) to manage where kernels get installed, which get booted, etc. I wanted to be able to update the device kernel remotely (without having to use the USB console). Needing to change u-boot settings at all is problematic for that situation. With EFI boot there's also no need to load an initramfs nor a device tree to memory either, though there can be use cases (e.g. full disk encryption) where you would still need an initramfs.