with new uboot env esspressobin v5 does not boot

[marcz]

I try to boot for first time an espresso bin v5, I followed the advice in  (Espressobin / Ultra – Armbian](https://www.armbian.com/espressobin/) and updated my uboot, and reset the environment.

env default -a
## Resetting to default environment

I added the image and fdt address with:

setenv fdt_name boot/dtb/marvell/armada-3720-espressobin.dtb
setenv image_name boot/Image
setenv scriptaddr 0x6d00000

 

The last line is after seeing in the forum that this setting has been erased when resetting the default environment

 

my environment is now:

Quote

Marvell>> printenv
arch=arm
baudrate=115200
board=mvebu_armada-37xx
board_name=mvebu_armada-37xx
bootcmd=run get_images; run set_bootargs; run load_script;booti $kernel_addr $ramfs_addr $fdt_addr
bootdelay=4
console=console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000
cpu=armv8
eth1addr=00:51:82:11:22:01
eth2addr=00:51:82:11:22:02
eth3addr=00:51:82:11:22:03
ethact=neta@30000
ethaddr=00:51:82:11:22:00
ethprime=eth0
extra_params=pci=pcie_bus_safe
fdt_addr_r=0x6f00000
fdt_high=0xffffffffffffffff
fdt_name=boot/dtb/marvell/armada-3720-espressobin.dtb
fdtcontroladdr=7f62d490
gatewayip=10.4.50.254
get_images=tftpboot $kernel_addr_r $image_name; tftpboot $fdt_addr_r $fdt_name; run get_ramfs
get_ramfs=if test "${ramfs_name}" != "-"; then setenv ramdisk_addr_r 0x8000000; tftpboot $ramdisk_addr_r $ramfs_name; else setenv ramdisk_addr_ri
hostname=marvell
image_name=boot/Image
initrd_addr=0xa00000
initrd_size=0x2000000
ipaddr=0.0.0.0
kernel_addr_r=0x7000000
load_script=if test -e mmc 0:1 boot/boot.scr; then echo "... booting from SD";setenv boot_interface mmc;else echo "... booting from USB/SATA";usi
loadaddr=0x6000000
netdev=eth0
netmask=255.255.255.0
ramdisk_addr_r=0x8000000
ramfs_name=-
root=root=/dev/nfs rw
rootpath=/srv/nfs/
scriptaddr=0x6d00000
serverip=0.0.0.0
set_bootargs=setenv bootargs $console $root ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none nfsroot=$serverip:$rootpath,tcp,v3 $e
soc=mvebu
stderr=serial@12000
stdin=serial@12000
stdout=serial@12000
vendor=Marvell

When I try to boot, it seems to load the initrd but never complete the boot I get:

Marvell>> boot
*** ERROR: `serverip' not set
*** ERROR: `serverip' not set
... booting from SD
1631 bytes read in 9 ms (176.8 KiB/s)
## Executing script at 00800000
load - load binary file from a filesystem

Usage:
load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]]
    - Load binary file 'filename' from partition 'part' on device
       type 'interface' instance 'dev' to address 'addr' in memory.
      'bytes' gives the size to load in bytes.
      If 'bytes' is 0 or omitted, the file is read until the end.
      'pos' gives the file byte position to start reading from.
      If 'pos' is 0 or omitted, the file is read from the start.
## Info: input data size = 2100 = 0x834
load - load binary file from a filesystem

Usage:
load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]]
    - Load binary file 'filename' from partition 'part' on device
       type 'interface' instance 'dev' to address 'addr' in memory.
      'bytes' gives the size to load in bytes.
      If 'bytes' is 0 or omitted, the file is read until the end.
      'pos' gives the file byte position to start reading from.
      If 'pos' is 0 or omitted, the file is read from the start.
bootm - boot application image from memory

Usage:
bootm [addr [arg ...]]
    - boot application image stored in memory
        passing arguments 'arg ...'; when booting a Linux kernel,
        'arg' can be the address of an initrd image
        When booting a Linux kernel which requires a flat device-tree
        a third argument is required which is the address of the
        device-tree blob. To boot that kernel without an initrd image,
        use a '-' for the second argument. If you do not pass a third
        a bd_info struct will be passed instead

Sub-commands to do part of the bootm sequence.  The sub-commands must be
issued in the order below (it's ok to not issue all sub-commands):
        start [addr [arg ...]]
        loados  - load OS image
        ramdisk - relocate initrd, set env initrd_start/initrd_end
        fdt     - relocate flat device tree
        cmdline - OS specific command line processing/setup
        bdt     - OS specific bd_t processing
        prep    - OS specific prep before relocation or go
        go      - start OS
21764608 bytes read in 2021 ms (10.3 MiB/s)
ext4load - load binary file from a Ext4 filesystem

Usage:
ext4load <interface> [<dev[:part]> [addr [filename [bytes [pos]]]]]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext4 filesystem
11618 bytes read in 12 ms (945.3 KiB/s)
## Flattened Device Tree blob at 06f00000
   Booting using the fdt blob at 0x6f00000
   Using Device Tree in place at 0000000006f00000, end 0000000006f05d61

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 5.15.48-mvebu64 (root@8b3d501f9218) (aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 8.3.0, GNU ld (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 2.32.0.20190321) #22.05.3 SMP PREEMPT Wed Jun 22 07:22:16 UTC 2022
[    0.000000] Machine model: Globalscale Marvell ESPRESSOBin Board
[    0.000000] earlycon: ar3700_uart0 at MMIO 0x00000000d0012000 (options '')
  
..... Omitted a long boot log ....
  
  [    2.376178] Key type fscrypt-provisioning registered
[    2.383950] Btrfs loaded, crc32c=crc32c-generic, zoned=no, fsverity=no
[    2.394740] d0012000.serial: ttyMV0 at MMIO 0xd0012000 (irq = 0, base_baud = 1562500) is a mvebu-uart
[    2.404251] printk: console [ttyMV0] enabled
[    2.404251] printk: console [ttyMV0] enabled
[    2.412987] printk: bootconsole [ar3700_uart0] disabled
[    2.412987] printk: bootconsole [ar3700_uart0] disabled
[    2.425972] xenon-sdhci d00d0000.sdhci: Got CD GPIO
[    2.464648] mmc0: SDHCI controller on d00d0000.sdhci [d00d0000.sdhci] using ADMA
[    2.473851] Waiting for root device ...
[    2.512635] mmc0: new high speed SDHC card at address d6d7
[    2.520455] mmcblk0: mmc0:d6d7 SU08G 7.40 GiB
[    2.531514]  mmcblk0: p1

 

It seems that my boot env is incomplete.

 

I tried with the last bullseyes and bookworm image, with the same result.

 

I also tried the instructions in Armbian Documentation - Esspresso bin even if it seems obsolete by now, as it uses old uboot variable names, and contain a booiti command after sourcing the boot.scr script which itself contain the booti command; but I got the same result, even if the inird addr was distinct.

 

Please what is wrong, and what I'm missing in this uboot environment.

[bschnei]

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.

[marcz]

Yes my environment is broken, this is the environment that I got by downloading the new u-boot image and resetting the environment to the default one. Now I am quite lost I don't know how to recover a proper environment.

 

It seems that these erroneous root variables are in any case overridden by the boot.scr script. I see that some variables are necessary for running this script. At least ${devtype}, ${devnum}, ${distro_bootpart}, ${scriptaddr},  ${prefix}, ${filesize}

some are easy like

devtype=mmc

devnum=0

distro_bootpart=1

prefix=boot/

 

I have seen elsewhere, but I don't know how to check it

scriptaddr=0x6d00000

 

For filesize I have no idea

 

in any case my load_script does not work.

If somebody could help me to recover a proper basic environment, it would help a lot.

 

 

 

[bschnei]

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

[marcz]

I have set this value as you told @bschnei, and it changes nothing. After examining boot.scr that is first loaded, I see that root is reset in this script so the root env value does not matter.

 

After setting the variables like cited above, it find the script it seems to load armbianEnv.txt but fail on the next load. but some parameter that are not set in my env nor ArmbianEnv.txt seem missing like this file size.

 

I have only reset the default environment and set few variables, so it is easy to reset again. But I don't know how to find the extra parameters that are not set in armbianEnv.txt nor boot.scr.

[marcz]

@bschnei you say that you don't use the distribution, I don't know what you meant.

But if you have a similar board that is running Armbian, it could help if you tell me the image version and the environment you use.

Edited March 13 by marcz

[bschnei]

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?

[marcz]

 Nice to know about your fork of globalscale boot loader, I may go further deeper in your project later on.
 

For today I have no longer access to my board, I will post tomorrow the two files.

 

For specifying the device the ArmbianEnv.txt use an UUID, so it does not dépend of the location of the device.

[marcz]

The image contain in the boot/ directory:

Marvell >> ls mmc 0:1 boot/
<DIR>       4096 .
<DIR>       4096 ..
<SYM>         32 Image
<SYM>         28 dtb
<DIR>       4096 dtb-5.15.149-current-mvebu64
           38518 boot.bmp
               0 .next
<SYM>         32 uInitrd
            1592 boot.cmd
         4198770 System.map-5.15.149-current-mvebu64
              95 armbianEnv.txt
            1536 armbian_first_run.txt.template
            1664 boot.scr
         9681576 uInitrd-5.15.149-current-mvebu64
          193310 config-5.15.149-current-mvebu64
        21899776 vmlinuz-5.15.149-current-mvebu64
         9681512 initrd.img-5.15.149-current-mvebu64
<SYM>         39 fdt.dtb
        16578860 espressobin.itb

and the content of armbianEnv.txt is

board_version=v5
verbosity=1
rootdev=UUID=eb19bd31-6e1d-40ca-b936-d2823be614de
rootfstype=ext4

The boot.cmd or boot.scr is

"# Some tests to try to keep compatibility with old variables
if test -z "${kernel_addr_r}"; then
  setenv kernel_addr_r $kernel_addr
fi
if test -z "${ramdisk_addr_r}"; then
  setenv ramdisk_addr_r $initrd_addr
fi
if test -z "${fdt_addr_r}"; then
  setenv fdt_addr_r $fdt_addr
fi
if test -z "${distro_bootpart}"; then
  setenv distro_bootpart 1
fi
if test -z "${devtype}"; then
  setenv devtype $boot_interface
fi

load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}armbianEnv.txt
env import -t ${scriptaddr} ${filesize}

setenv bootargs "$console root=${rootdev} rootfstype=${rootfstype} rootwait loglevel=${verbosity} usb-storage.quirks=${usbstoragequirks}  ${extraargs}"

load $devtype ${devnum}:${distro_bootpart} $ramdisk_addr_r ${prefix}espressobin.itb

bootm ${ramdisk_addr_r}#$board_version

# fallback to non-FIT image
if test -z "${image_name}"; then
  setenv image_name "Image"
fi
if test -z "${initrd_image}"; then
  setenv initrd_image "uInitrd"
 fi
if test -z "${fdt_name}"; then
  if test -z "${fdtfile}"; then
    setenv fdt_name "dtb/marvell/armada-3720-espressobin.dtb"
  else
    setenv fdt_name "dtb/$fdtfile"
  fi
fi
load $devtype ${devnum}:$distro_bootpart $kernel_addr_r ${prefix}$image_name
load $devtype ${devnum}:$distro_bootpart $ramdisk_addr_r ${prefix}$initrd_image
load $devtype ${devnum}:$distro_bootpart $fdt_addr_r ${prefix}$fdt_name

booti $kernel_addr_r $ramdisk_addr_r $fdt_addr_r
# mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

When trying to load in memory boot.scr and source it it fails, so to locate the problem I rather walk through the script step by step.

I can load espressobin.itb:

Marvell>> load $devtype ${devnum}:${distro_bootpart} $ramdisk_addr_r ${prefix}espressobin.itb
16578860 bytes read in 730 ms (21.7 MiB/s)

but when trying  to boot:

Marvell>> bootm ${ramdisk_addr_r}#$board_version
Wrong Image Format for bootm command
ERROR: can't get kernel image!

I don't understand why I get this wrong image format.

 

The following fallback script does not work either, everything go well until the booti command then

Marvell>> booti $kernel_addr_r $ramdisk_addr_r $fdt_addr_r
## Loading init Ramdisk from Legacy Image at 08000000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    9681512 Bytes = 9.2 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 06f00000
   Booting using the fdt blob at 0x6f00000
   Loading Ramdisk to 7ecf0000, end 7f62ba68 ... OK
   Using Device Tree in place at 0000000006f00000, end 0000000006f05d61

Starting kernel ...

"Synchronous Abort" handler, esr 0x02000000

 

[marcz]

to debug I launched the kernel with:

  setenv fdt_name dtb/marvell/armada-3720-espressobin.dtb
  setenv bootargs root=/dev/mmcblk0p1 rootwait ${console}
  ext4load mmc 0:1 $initrd_addr boot/uInitrd
  ext4load mmc 0:1 $kernel_addr_r boot/Image
  ext4load mmc 0:1 $fdt_addr_r boot/${fdt_name}
  booti $kernel_addr_r $initrd_addr $fdt_addr_r

And it boots on the console, I will explore how I can set a more proper boot process.

Edited March 14 by marcz

[bschnei]

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.

[marcz]

I now use some uboot settings analogous to what you propose on the base of archinux configuration. But as you said value coded in uboot spi have to be changed when you update the kernel. This is the purpose of not storing kernel dependent values in the spi, but loading them from the device, like it is done in ArmbianEnv.txt or in archlinux in /boot/uEnv.txt.

 

What I still does not understand is while the itb image, gives an error when trying to bootm from it.

 

I agree that chaining UEFI bootloader should be a more flexible option, after updating the kernel it is very easy to do an update-grub, and let it generate the initrd and new grub code. And you don't have to touch the uboot itself. I have to learn more about uboot UEFI, before being able to try this option. I have never used the bootflows, so I have to learn.

 

I have seen an interesting thread on the boot process in this forum in The boot process and various devices , beginning by a good summary by  @ManoftheSea

 

@bschnei you seem to have expertise in uboot, you should contribute to Armbian. Armbian is not to be despised, its strength is the maintenance of many sbc kernels that are not available in Debian or archlinux. And they have developed a build system that allow the update of so many device, a task out of reach of an individual alone.

 

 

[bschnei]

Quote

value coded in uboot spi have to be changed when you update the kernel

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.

 

Edited March 18 by bschnei