Espressobin Update U-Boot Environment Without USB/UART?

[LostZimbo]

Morning All,

 

Around a year and a half ago I found the USB port from my Espressobin V5 had broken off. This has not greatly affected me because the board itself continued to operate perfectly up to the point of merging with the mainline kernel 5.x which it simply will not boot, I am assuming because a new boot script needs to be set for the device as described on the download page ( https://www.armbian.com/espressobin/ ) but of course I am unable to access the U-Boot command without serial communication. I have set the kernel update on hold thus far, but this of course cannot hold forever. Is there anyway to update the boot script without access to serial communication on the device? I still have SSH control and it is booting a 4.19 kernel  without a hitch.

 

My Espressobin is currently being used as a subnet: LAN support where required, vpn server, NFS server, 2.4 and 5GHz wifi networks that actually outperform the piece of garbage router that my ISP sent to me. I love it. I would eventually replace it with whichever is newest from Globalscale but for now it is doing what I need, just have to figure out how to update it.

[barish]

There is no way I know of to change environment parameters or U-Boot of the onboard SPI without UART access (I broke one off myself, it seemed to be very poorly connected to the board at the v5 models).

If you compare the contents of  the /boot directory: has there changed anything from the version that was running and the one you are trying now? Because, if boot.cmd (boot.scr) and armbianEnv.txt are still the same, the old U-Boot shouldn't have issues booting. Have a look if you can use the old files instead of  the ones that come with the new Armbian, maybe that works (actually, boot.scr is the important file, the compiled  version of boot.cmd ).

 

[umiddelb]

The spi flash memory (with the u-boot environment stored inside) is accessible from the command line. Please check if the corresponding driver is loaded via dmesg. It should look like:

[    1.878826] spi-nor spi0.0: w25q32dw (4096 Kbytes)
[    1.878850] 2 cmdlinepart partitions found on MTD device spi0.0
[    1.878854] Creating 2 MTD partitions on "spi0.0":
[    1.878870] 0x000000000000-0x0000003f0000 : "uboot"
[    1.888884] 0x0000003f0000-0x000000400000 : "uboot-environment"

The partitioning information is passed as a command line parameter to the kernel (last parameter in this case):

console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=UUID=c2bdee11-6a88-46c1-8630-b70864d535bb rootfstype=ext4 rootwait loglevel=1 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u mtdparts=spi0.0:4032k(uboot),64k(uboot-environment)

 You need to install the package u-boot-tools containing the userland tools and you need to configure the correct offsets:

uli@ebin:~$ cat /etc/fw_env.config
# device name   device offset   env. size   flash sector size  number of sectors
/dev/mtd1       0x00000000      0x00010000  0x1000             0x10

Then fw_printenv / fw_setenv will help you to modify the u-boot environment:

uli@ebin:~$ sudo fw_printenv
arch=arm
baudrate=115200
board=mvebu_armada-37xx
board_name=mvebu_armada-37xx
boot_a_script=ext4load ${boot_interface} ${devnum}:1 ${scriptaddr} ${prefix}boot.scr;source ${scriptaddr};
boot_prefixes=/ /boot/
boot_targets=usb sata mmc1 mmc0
bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
bootcmd_mmc0=setenv devnum 0; setenv boot_interface mmc; run scan_dev_for_boot;
bootcmd_mmc1=setenv devnum 1; setenv boot_interface mmc; run scan_dev_for_boot;
bootcmd_sata=setenv devnum 0; scsi scan; scsi dev 0; setenv boot_interface scsi; run scan_dev_for_boot;
bootcmd_usb=setenv devnum 0; usb start;setenv boot_interface usb; run scan_dev_for_boot;
bootdelay=2
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
ethaddr=00:51:82:11:22:00
ethprime=eth0
extra_params=pci=pcie_bus_safe
fdt_addr=0x6000000
fdt_addr_r=0x6f00000
fdt_high=0xffffffffffffffff
fdt_name=fdt.dtb
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_r -;fi
hostname=marvell
image_name=Image
initrd_addr=0x1100000
initrd_image=uInitrd
initrd_size=0x2000000
ipaddr=0.0.0.0
kernel_addr=0x7000000
kernel_addr_r=0x7000000
loadaddr=0x8000000
netdev=eth0
netmask=255.255.255.0
ramdisk_addr_r=0x8000000
ramfs_name=-
root=root=/dev/nfs rw
rootpath=/srv/nfs/
scan_dev_for_boot=for prefix in ${boot_prefixes}; do echo ${prefix};run boot_a_script; done
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 $extra_params $cpuidle
soc=mvebu
vendor=Marvell

Unfortunately the offsets vary between the different u-boot versions, so you have to find out the correct one for your board.

fw_printenv will tell you if the CRC check fails meaning that the chosen offsets do not fit. 

[Pali]

On 11/25/2020 at 6:03 AM, umiddelb said:

Unfortunately the offsets vary between the different u-boot versions, so you have to find out the correct one for your board.

 

This is fixed in new U-Boot version, which automatically adjust kernel's DTS file to set correct offset ot these partitions.