bschnei

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.