marcz Posted March 7 Posted March 7 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. 0 Quote
bschnei Posted March 13 Posted March 13 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. 0 Quote
marcz Posted March 13 Author Posted March 13 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. 0 Quote
bschnei Posted March 13 Posted March 13 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 0 Quote
marcz Posted March 13 Author Posted March 13 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. 0 Quote
marcz Posted March 13 Author Posted March 13 (edited) @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 0 Quote
bschnei Posted March 13 Posted March 13 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? 0 Quote
marcz Posted March 13 Author Posted March 13 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. 0 Quote
marcz Posted March 14 Author Posted March 14 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 0 Quote
marcz Posted March 14 Author Posted March 14 (edited) 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 0 Quote
bschnei Posted March 14 Posted March 14 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. 0 Quote
marcz Posted March 16 Author Posted March 16 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. 0 Quote
bschnei Posted March 16 Posted March 16 (edited) 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 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.