bschnei

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.

Armbian is a distribution of Linux. I do not use it. I don't use the bootloader supplied here either. I build my own. My environment settings will not help you. My entire bootcmd is simply "bootflow scan" because I have configured U-Boot Standard Boot. I did that because I found all this script stuff to be very clunky just like you are experiencing yourself too Are you able to confirm that whatever the root= kernel parameter is being set to is in fact where the root of your filesystem is? For example if your filesystem is on a USB drive then mmcblk0 would be the wrong device. What are the full contents of boot.scr and ArmbianEnv.txt?

There is no such thing as a "proper" environment. The entire point is that the values can be adjusted to accommodate a variety of possible system configurations. Clearly the defaults don't work for your configuration and it would have been a good idea to test them before saving them to permanent storage with saveenv. I don't develop for the Armbian project nor use the distribution. I simply own a similar device. Your device is entirely recoverable but you need to be willing to help yourself by changing the u-boot environment variables. You can't make your situation worse by changing them temporarily and seeing if it solves your problems. Have you tried to change root environment variable as I already suggested? If you only have one partition on MMC then it probably needs to have a value of root=/dev/mmcblk0p1 rw

There are a lot of suboptimal things about the environment values that are causing most of the messages you are seeing, but the reason boot is ultimately failing is most likely because of your kernel parameter for the root filesystem being set to /dev/nfs. It's much more likely that your root filesystem is on /dev/mmcblk0p1 or one of the other local block devices.

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.