Jump to content
  • 0

Making EspressoBin V7 work in 2022 ...


fallen_aarch64

Question

Hi eveyone,

 

I am coming from a a hint off Github here: https://github.com/armbian/documentation/issues/165. Igor was so kind and redirected me to this community.

 

I am struggling since beginning christmas to get my EspressoBin to latest versions out of dusty 2018 images.


Device

EspressoBin v7 DDR4 1G 1000_800Mhz

 

Baseline - What did I do?

- Update U-Boot according https://www.armbian.com/espressobin to devel-18.12.3

- Flashed SD-Card with armbian Focal via Balena according https://docs.armbian.com/User-Guide_Getting-Started/

- Updated Boot Environment according https://www.armbian.com/espressobin/#kernels-archive-all

 

 

Problem Description

- U-Boot Loads and starts over to boot from SD-Card

- Booting from SD fails with

 

Marvell>> boot *** ERROR: serverip' not set
*** ERROR: serverip' not set Bad Linux ARM64 Image magic!

 

I would be very grateful for any hints how to get armbian booted on the EspressoBin in 2022!

Happy Holidays to all. cheers

 

 

Full Logs

U-Boot 2018.03-devel-18.12.3-gc9aa92ce70-armbian (Sep 18 2020 - 10:07:21 +0200)

Model: Marvell Armada 3720 Community Board ESPRESSOBin
CPU 1000 [MHz]
L2 800 [MHz]
TClock 200 [MHz]
DDR 800 [MHz]
DRAM: 1 GiB
Comphy chip #0:
Comphy-0: USB3 5 Gbps
Comphy-1: PEX0 2.5 Gbps
Comphy-2: SATA0 6 Gbps
SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs
PCIE-0: Link up
MMC: sdhci@d0000: 0
Loading Environment from SPI Flash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB
OK
Model: Marvell Armada 3720 Community Board ESPRESSOBin
Net: eth0: neta@30000 [PRIME]

 

https://github.com/armbian/documentation/issues/165

Link to comment
Share on other sites

Recommended Posts

Help us fund some #badass gear for our continuous integration build framework

  • 0
8 hours ago, ManoftheSea said:

As far as matching RAM type and processor max speed, that's already on the download page, and still relevant, so we wouldn't change it.

To my understanding, these firmware files would need to be rebuilt based on the mainline TFA and uboot.

Link to comment
Share on other sites

  • 0

Distroboot with a Flattened uImage Tree?  Don't mind if I do!

 

Take a file like "espressobin.its"

Spoiler

/dts-v1/;

/ {
    description = "EspressoBIN 3720 FIT Image";
    #address-cells = <1>;

    images {
        kernel {
            description = "Kernel";
            data = /incbin/("/boot/Image");
            type = "kernel";
            arch = "arm64";
            os = "linux";
            compression = "none";
            load = <0x40480000>;
            entry = <0x40480000>;
            hash {
                algo = "sha1";
            };
        };
        fdt-v5 {
            description = "DTB";
            data = /incbin/("/boot/dtb/marvell/armada-3720-espressobin.dtb");
            type = "flat_dt";
            arch = "arm64";
            compression = "none";
            load = <0x43000000>;
            entry = <0x43000000>;
            hash {
                algo = "sha1";
            };
        };
        fdt-v7 {
            description = "DTB";
            data = /incbin/("/boot/dtb/marvell/armada-3720-espressobin-v7.dtb");
            type = "flat_dt";
            arch = "arm64";
            compression = "none";
            load = <0x43000000>;
            entry = <0x43000000>;
            hash {
                algo = "sha1";
            };
        };
        initrd {
            description = "Initrd";
            data = /incbin/("/boot/uInitrd");
            type = "ramdisk";
            arch = "arm64";
            os = "linux";
            compression = "none";
            hash {
                algo = "sha1";
            };
        };
    };

    configurations {
        default = "standard";
        standard {
            description = "Standard Boot";
            kernel = "kernel";
            fdt = "fdt-v7";
            ramdisk = "initrd";
            hash {
                algo = "sha1";
            };
        };
        v5-board {
            description = "Standard on v5 Boot";
            kernel = "kernel";
            fdt = "fdt-v5";
            ramdisk = "initrd";
            hash {
                algo = "sha1";
            };
        };
    };
};

And then you "mkimage -f espressobin.its espressobin.itb" to get the kernel, fdt, and ramdisk all in one.  Apparently, u-boot can "bootm ${addr}#standard" that file.

Link to comment
Share on other sites

  • 0
On 4/13/2022 at 9:03 AM, Pali said:

About criptaddr - this looks like a bug in U-Boot and needs to be fixed. It really should be scriptaddr. I will try to look at it where is the issue. Last time I tested it I did not see such issue.

 

I tried to debug this issue, but I'm not able to reproduce it. I always have correct scriptaddr env name. See:

TIM-1.0
mv_ddr-devel-g7753d4b3e420 DDR3 16b 1GB 2CS
WTMI-devel-18.12.1-1d977157e371
WTMI: system early-init
CPU VDD voltage default value: 1.155V
Setting clocks: CPU 1000 MHz, DDR 800 MHz
CZ.NIC's Armada 3720 Secure Firmware v2021.09.07-48-geb1ac8f98b81 (Apr 14 2022 10:11:16)
Running on ESPRESSObin
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v2.6(release):v2.6-573-g1000e7dbd297
NOTICE:  BL1: Built : 12:47:53, Mar 23 2022
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v2.6(release):v2.6-573-g1000e7dbd297
NOTICE:  BL2: Built : 12:47:53, Mar 23 2022
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v2.6(release):v2.6-573-g1000e7dbd297
NOTICE:  BL31: Built : 14:04:46, Mar 23 2022


U-Boot 2022.04 (Apr 14 2022 - 10:33:14 +0200)

DRAM:  1 GiB
Core:  38 devices, 20 uclasses, devicetree: separate
WDT:   Not starting watchdog@8300
Comphy chip #0:
Comphy-0: USB3_HOST0    5 Gbps
Comphy-1: PEX0          5 Gbps
Comphy-2: SATA0         6 Gbps
SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs
PCIe: Link up
MMC:   sdhci@d0000: 0, sdhci@d8000: 1
Loading Environment from SPIFlash... SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB
OK
Model: Globalscale Marvell ESPRESSOBin Board
Net:   eth0: ethernet@30000 [PRIME]
=> env default -a
## Resetting to default environment
=> printenv
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_efi_bootmgr=if fdt addr ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr;fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
boot_net_usb_start=usb start
boot_pci_enum=pci enum
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_syslinux_conf=extlinux/extlinux.conf
boot_targets=mmc1 mmc0 usb0 scsi0 pxe dhcp
bootcmd=run distro_bootcmd
bootcmd_dhcp=devtype=dhcp; run boot_net_usb_start; run boot_pci_enum; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
bootcmd_mmc0=devnum=0; run mmc_boot
bootcmd_mmc1=devnum=1; run mmc_boot
bootcmd_pxe=run boot_net_usb_start; run boot_pci_enum; dhcp; if pxe get; then pxe boot; fi
bootcmd_scsi0=devnum=0; run scsi_boot
bootcmd_usb0=devnum=0; run usb_boot
distro_bootcmd=scsi_need_init=; setenv nvme_need_init; for target in ${boot_targets}; do run bootcmd_${target}; done
efi_dtb_prefixes=/ /dtb/ /dtb/current/
eth1addr=XX:XX:XX:XX:XX:XX
eth2addr=XX:XX:XX:XX:XX:XX
eth3addr=XX:XX:XX:XX:XX:XX
ethaddr=XX:XX:XX:XX:XX:XX
fdt_addr=0x6f00000
fdt_addr_r=0x6f00000
fdtfile=marvell/armada-3720-espressobin.dtb
kernel_addr=0x7000000
kernel_addr_r=0x7000000
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi
nvme_boot=run boot_pci_enum; run nvme_init; if nvme dev ${devnum}; then devtype=nvme; run scan_dev_for_boot_part; fi
nvme_init=if ${nvme_need_init}; then setenv nvme_need_init false; nvme scan; fi
pxefile_addr_r=0x6e00000
ramdisk_addr_r=0xa000000
sata_boot=if sata dev ${devnum}; then devtype=sata; run scan_dev_for_boot_part; fi
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done; setenv devplist
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;run boot_efi_bootmgr;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then echo Found EFI removable media binary efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x6d00000
scsi_boot=run boot_pci_enum; run scsi_init; if scsi dev ${devnum}; then devtype=scsi; run scan_dev_for_boot_part; fi
scsi_init=if ${scsi_need_init}; then scsi_need_init=false; scsi scan; fi
usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi

Environment size: 4227/65532 bytes
=>

 

I just masked MAC addresses from the output.

Link to comment
Share on other sites

  • 0

I have tested it on two different A3720 devices and on both it worked. And yes, it is clean U-Boot 2022.04 without any additional patches. So really do not know what can trigger this issue. There can be memory corruption or any other issue which could depend on linker layout, memory usage, etc... But as I cannot reproduce it, it is really hard for me to debug.

Link to comment
Share on other sites

  • 0

I'm seeing just about everything you are, except that i get "criptaddr". 

 

Quote

TIM-1.0                                                                         
mv_ddr-devel-g251bc63 DDR4 16b 1GB 1CS                                          
WTMI-devel-18.12.1-1d97715                                                      
WTMI: system early-init                                                         
SVC REV: 5, CPU VDD voltage: 1.143V                                             
Setting clocks: CPU 1000 MHz, DDR 800 MHz                                       
CZ.NIC's Armada 3720 Secure Firmware 0b68a33-dirty (Apr 14 2022 20:35:06)       
Running on ESPRESSObin                                                          
NOTICE:  Booting Trusted Firmware                                               
NOTICE:  BL1: v2.6(release):86329689                                            
NOTICE:  BL1: Built : 20:38:18, Apr 14 2022                                     
NOTICE:  BL1: Booting BL2                                                       
NOTICE:  BL2: v2.6(release):86329689                                            
NOTICE:  BL2: Built : 20:38:18, Apr 14 2022                                     
NOTICE:  BL1: Booting BL31                                                      
NOTICE:  BL31: v2.6(release):86329689                                           
NOTICE:  BL31: Built : 20:38:18, Apr 14 2022

 

 

U-Boot 2022.04-armbian (Apr 14 2022 - 20:34:59 +0000)                           
                                                                                
DRAM:  1 GiB                                                                    
Core:  38 devices, 20 uclasses, devicetree: separate                            
WDT:   Not starting watchdog@8300                                               
Comphy chip #0:                                                                 
Comphy-0: USB3_HOST0    5 Gbps                                                  
Comphy-1: PEX0          5 Gbps                                                  
Comphy-2: SATA0         6 Gbps                                                  
SATA link 0 timeout.                                                            
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode                       
flags: ncq led only pmp fbss pio slum part sxs                                  
PCIe: Link down                                                                 
MMC:   sdhci@d0000: 0, sdhci@d8000: 1                                           
Loading Environment from SPIFlash... SF: Detected mx25u3235f with page size 256B
OK                                                                              
Model: Globalscale Marvell ESPRESSOBin Board                                    
Net:   eth0: ethernet@30000                         

These Comphy numbers are... well, they're different.  I want to say they're wrong.  I'm used to seeing 5/2.5/5, and now it's 5/5/6.  I don't have anything in the ports to check them, though.

Link to comment
Share on other sites

  • 0

USB 3.0 is 5Gbps, PCIe 2.1 is 5Gbps and SATA is 6Gbps.

 

For loading you should use some unused space in RAM. Default value of of those variables should contain appropriate values. And they may change between releases, that is why addresses are in variables.

Link to comment
Share on other sites

  • 0

Thanks Pali.  I was hoping for a bit more of the "why were these values chosen, what goes into that decision" rather than just "use u-boot's values", but I'll try to learn on my own.

 

Current uboot (2022.04) works on espressobin, as well as both 5.15 and 5.17 kernels.  Default environment variables will work with the changes in my espressobin_distroboot PR, which should be pulled in anytime.  However, I cannot get FIT images to work.  This requires a change on the defconfig for the espressobin.  And, maybe it doesn't work, and that's why it's not enabled for this device.

 

Spoiler

=>  load mmc 0:1 $ramdisk_addr_r /boot/espressobin.itb                          
29888848 bytes read in 1262 ms (22.6 MiB/s)                                     
=> bootm $ramdisk_addr_r                                                        
## Loading kernel from FIT Image at 0a000000 ...                                
   Using 'standard' configuration                                               
   Verifying Hash Integrity ... OK                                              
   Trying 'kernel' kernel subimage                                              
     Description:  Kernel                                                       
     Type:         Kernel Image                                                 
     Compression:  uncompressed                                                 
     Data Start:   0x0a0000c0                                                   
     Data Size:    21899776 Bytes = 20.9 MiB                                    
     Architecture: AArch64                                                      
     OS:           Linux                                                        
     Load Address: 0x40480000                                                   
     Entry Point:  0x40480000                                                   
     Hash algo:    sha1                                                         
     Hash value:   6fb3cefb349578c7ed25cc36fa923a6c7ab822cb                     
   Verifying Hash Integrity ... sha1+ OK                                        
## Loading ramdisk from FIT Image at 0a000000 ...                               
   Using 'standard' configuration                                               
   Verifying Hash Integrity ... OK                                              
   Trying 'initrd' ramdisk subimage                                             
     Description:  Initrd                                                       
     Type:         RAMDisk Image                                                
     Compression:  uncompressed                                                 
     Data Start:   0x0b4e8820                                                   
     Data Size:    7963491 Bytes = 7.6 MiB                                      
     Architecture: AArch64                                                      
     OS:           Linux                                                        
     Load Address: unavailable                                                  
     Entry Point:  unavailable                                                  
     Hash algo:    sha1                                                         
     Hash value:   879fe964b86712f47b2abe7891f906d0cdc650d9                     
   Verifying Hash Integrity ... sha1+ OK                                        
## Loading fdt from FIT Image at 0a000000 ...                                   
   Using 'standard' configuration                                               
   Verifying Hash Integrity ... OK                                              
   Trying 'fdt-v7' fdt subimage                                                 
     Description:  DTB                                                          
     Type:         Flat Device Tree                                             
     Compression:  uncompressed                                                 
     Data Start:   0x0b4e59d0                                                   
     Data Size:    11646 Bytes = 11.4 KiB                                       
     Architecture: AArch64                                                      
     Load Address: 0x43000000                                                   
     Hash algo:    sha1                                                         
     Hash value:   efafad852192004f472258b90d71203dcb5b1a1f                     
   Verifying Hash Integrity ... sha1+ OK                                        
   Loading fdt from 0x0b4e59d0 to 0x43000000                                    
"Synchronous Abort" handler, esr 0x96000045                                     
elr: 0000000000092f5c lr : 0000000000009948 (reloc)                             
elr: 000000003ff9cf5c lr : 000000003ff13948                                     
x0 : 0000000043000000 x1 : 000000000b4e59d0                                     
x2 : 0000000000002d7e x3 : 0000000000000000                                     
x4 : 7e2d0000edfe0dd0 x5 : 0000000000000004                                     
x6 : 000000003ffac5ff x7 : 0000000000000003                                     
x8 : 000000000a000000 x9 : 0000000000000008                                     
x10: 00000000014e8740 x11: 000000003faf671c                                     
x12: 00000000014e87bc x13: 000000003faf672c                                     
x14: 000000000a000000 x15: 0000000000000021                                     
x16: 000000003ff4ffb0 x17: 0000001601488416                                     
x18: 000000003faf9dd0 x19: 00000000014e5970                                     
x20: 000000000a000000 x21: 0000000000000008                                     
x22: 000000003ffad54f x23: 0000000000002d7e                                     
x24: 000000000b4e59ac x25: 000000003fc12390                                     
x26: 000000000bc80c50 x27: 0000000043000000                                     
x28: 000000000b4e59d0 x29: 000000003faf6820                                     
                                                                                
Code: eb03005f 540001c1 d65f03c0 f8636824 (f8236804)                            
Resetting CPU ...                                                               
                                                                                
resetting ...                                    

 

Link to comment
Share on other sites

  • 0
4 minutes ago, ManoftheSea said:

why were these values chosen, what goes into that decision

 

IIRC those were chosen as the first available space for some common image sizes.

 

6 minutes ago, ManoftheSea said:

However, I cannot get FIT images to work.

 

     Load Address: 0x40480000

     Load Address: 0x43000000

 

I do not have full knowledge of FIT images, but above addresses seems to be wrong. They are above 1GB of space and therefore it is required to have at least 2GB of RAM. If you have less then

 

9 minutes ago, ManoftheSea said:

   Loading fdt from 0x0b4e59d0 to 0x43000000                                    
"Synchronous Abort" handler, esr 0x96000045                                     

 

this is expected - CRASH.

 

Could you chose lower address for loading of those FIT sub-images?

Link to comment
Share on other sites

  • 0
24 minutes ago, Pali said:

Could you chose lower address for loading of those FIT sub-images?

Okay, that makes sense.  Can I get your commentary on the rest of the fit description?  Should I just move everything down by 512 MB by replacing 0x4 with 0x2?

Spoiler

/dts-v1/;

/ {
    description = "EspressoBIN 3720 FIT Image";
    #address-cells = <1>;

    images {
        kernel {
            description = "Kernel";
            data = /incbin/("/boot/Image");
            type = "kernel";
            arch = "arm64";
            os = "linux";
            compression = "none";
            load = <0x40480000>;
            entry = <0x40480000>;
            hash {
                algo = "sha1";
            };
        };
        fdt-v5 {
            description = "DTB";
            data = /incbin/("/boot/dtb/marvell/armada-3720-espressobin.dtb");
            type = "flat_dt";
            arch = "arm64";
            compression = "none";
            load = <0x43000000>;
            entry = <0x43000000>;
            hash {
                algo = "sha1";
            };
        };
        fdt-v7 {
            description = "DTB";
            data = /incbin/("/boot/dtb/marvell/armada-3720-espressobin-v7.dtb");
            type = "flat_dt";
            arch = "arm64";
            compression = "none";
            load = <0x43000000>;
            entry = <0x43000000>;
            hash {
                algo = "sha1";
            };
        };
        initrd {
            description = "Initrd";
            data = /incbin/("/boot/uInitrd");
            type = "ramdisk";
            arch = "arm64";
            os = "linux";
            compression = "none";
            hash {
                algo = "sha1";
            };
        };
    };

    configurations {
        default = "standard";
        standard {
            description = "Standard Boot";
            kernel = "kernel";
            fdt = "fdt-v7";
            ramdisk = "initrd";
            hash {
                algo = "sha1";
            };
        };
        v5-board {
            description = "Standard on v5 Boot";
            kernel = "kernel";
            fdt = "fdt-v5";
            ramdisk = "initrd";
            hash {
                algo = "sha1";
            };
        };
    };
};

[Edit] Or... I suppose I can use the kernel_addr_r (0x07000000) and fdt_addr_r (0x06f00000) values here.  Sure, I'mma try that.

Link to comment
Share on other sites

  • 0

There are Espressobin variants with just 512MB of memory. So if your image needs to be compatible with more variants, ensure that you place all parts in first 512 MB of RAM. I'm not sure where is running U-Boot after relocation and where it is malloc area. So choose address which does not conflict with it.

 

You can look at RAM layout used on A3720 CPU:

https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/marvell/armada/a3k/common/include/platform_def.h?h=v2.6

Link to comment
Share on other sites

  • 0
On 4/14/2022 at 1:44 PM, ManoftheSea said:

I wouldn't have believed myself if I hadn't seen it and tried it a few times

https://wiki.gentoo.org/wiki/ESPRESSOBin#Mainline_u-boot
"Note this variable is defined correctly in the header file, but somehow gets dropped from the default env (and is one of the required distro vars)."

 

It's not just me.  But I flashed a v5 (thanks Lanefu) and the default env came up with the correct scriptaddr, while each time I had flashed my v7 I was only getting criptaddr.  And the gentoo page says they didn't get the var at all, with no mention of version of either u-boot or ebin.  But at least there's a note about how to fix it.

 

I got FIT images working, even including lzma compressed kernels.  That's pretty cool!  But it looks like compressed kernels on ARM64 is dependent on the debian kernel packaging.  I'm not sure if we benefit from reducing sizes from 21 megs to 6.5 megs by creating a lot of difference from debian upstream.

Link to comment
Share on other sites

  • 0

Ensign's Log, stardate... uh, today.

 

I've contributed changes that build the FIT image as part of /etc/initramfs/post-update.d/99-uboot-fit, which means it'll be updated when new kernels are installed.

 

I've also contributed changes that modify the boot.scr.uimg to use the FIT image rather than the legacy images, and which allows setting "board_version" in armbianEnv.txt to identify which FDT to use from the FIT image.  Options are "v5" and "v7", and the only known difference is the ordering of the ethernet ports.

Link to comment
Share on other sites

  • 0

I flashed my espressobin v7 with

bubt flash-image-DDR4-1g_1cs_5-1000_800.bin spi usb

 

and set u-boot prompt:

 

printenv ethaddr

env default -a

saveenv

 

After the boot 
printenv:

 

TIM-1.0
mv_ddr-devel-g251bc63 DDR4 16b 1GB 1CS
WTMI-devel-18.12.1-1d97715
WTMI: system early-init
CPU VDD voltage default value: 1.155V
Setting clocks: CPU 1000 MHz, DDR 800 MHz
CZ.NIC's Armada 3720 Secure Firmware 0b68a33-dirty (May 16 2022 17:51:06)
Running on ESPRESSObin
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v2.6(release):a921da5e
NOTICE:  BL1: Built : 17:54:27, May 16 2022
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v2.6(release):a921da5e
NOTICE:  BL2: Built : 17:54:27, May 16 2022
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v2.6(release):a921da5e
NOTICE:  BL31: Built : 17:54:27, May 16 2022


U-Boot 2022.04-armbian (May 16 2022 - 17:50:52 +0000)

DRAM:  1 GiB
Core:  38 devices, 20 uclasses, devicetree: fit
WDT:   Not starting watchdog@8300
Comphy chip #0:
Comphy-0: USB3_HOST0    5 Gbps
Comphy-1: PEX0          5 Gbps
Comphy-2: SATA0         6 Gbps
SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs
PCIe: Link down
MMC:   sdhci@d0000: 0, sdhci@d8000: 1
Loading Environment from SPIFlash... SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB
OK
Model: Globalscale Marvell ESPRESSOBin Board
Net:   eth0: ethernet@30000
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Scanning disk sdhci@d0000.blk...
Scanning disk sdhci@d8000.blk...
Found 4 disks
No EFI system partition
ERROR: invalid device tree
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
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.
## Executing script at 06000000
Wrong image format for "source" command
SCRIPT FAILED: continuing...
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
ERROR: invalid device tree
starting USB...
Bus usb@58000: Register 2000104 NbrPorts 2
Starting the controller
USB XHCI 1.00
Bus usb@5e000: USB EHCI 1.00
scanning bus usb@58000 for devices... 1 USB Device(s) found
scanning bus usb@5e000 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

Device 0: unknown device
scanning bus for devices...

Device 0: unknown device
(NULL udevice *): mvneta_setup_txqs: can't create txq=0
BOOTP broadcast 1
timeout: packet not sent
BOOTP broadcast 2
timeout: packet not sent
BOOTP broadcast 3
timeout: packet not sent
BOOTP broadcast 4
timeout: packet not sent
..................
 ..............

 

 

any help? thanks more~

Link to comment
Share on other sites

  • 0
3 minutes ago, armbianfans023 said:
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
load - load binary file from a filesystem

 

Seems that you have broken /boot/boot.scr script on mmc 0:1 device (SD card?).

Link to comment
Share on other sites

  • 0

Hello,

As Pali said, there's probably a problem with the load command from the boot.scr.  If I had to bet, I'd say it's that the boot.scr uses a variable that u-boot doesn't have set, and therefore the number of parameters is wrong or malformed.

 

If you are able, the contents of "printenv" from the u-boot environment and the contents of the boot.cmd will help to clear this up. 

 

Looking at the version of boot.cmd in the armbian repository, there ought to be a fallback to booting by image name rather than FIT image.  I don't see these entries in your log.  Which may mean a problem with the assumptions in the script (That it will fall through) and therefore something I need to fix.

Link to comment
Share on other sites

  • 0

I apologize, I don't see printenv info. 

 

But I had a chance to follow the directions, and I found the issue.  From your u-boot environment, run the command

setenv scriptaddr $criptaddr

 

This will set the environment variable for "scriptaddr" to the incorrectly named "criptaddr", which has the right value.

 

@Pali It's not just me, that's three ebin v7's that have seen this issue from u-boot.  I can't explain why, because I can see as well as you can that the code for u-boot sets "scriptaddr" in the middle of a block of other environment variables.

Link to comment
Share on other sites

  • 0
2 minutes ago, ManoftheSea said:

@Pali It's not just me, that's three ebin v7's that have seen this issue from u-boot.  I can't explain why, because I can see as well as you can that the code for u-boot sets "scriptaddr" in the middle of a block of other environment variables.

 

I have no reason to not trust you. But also I have absolutely no idea how it can happen. And because I was not able to trigger this issue on two different Espressobin boards, I cannot debug it.

Link to comment
Share on other sites

  • 0

@pali I have a guess: I see in u-boot that there's an area reserved for ethaddr and eth{1,2,3}addr, as well as for fdtfile.  And in board/Marvell/mvebu_armada-37xx/board.c in board_late_init, there's a place where it writes the fdtfile based on whether there is emmc and ddr4.  Well, the v7 string is 3 characters longer than the v5 string, and it looks like the scriptaddr variable is the next variable.  Is it possible the call to "env default -a" is writing over the beginning of scriptaddr?  In which case, on an espressobin with emmc, we should see an even worse problem where the variable is named "iptaddr" afterward (because "-emmc" is 2 characters longer still than "-v7", so I speculate it'd eat two more characters out of "scriptaddr")

Link to comment
Share on other sites

  • 0

In file include/configs/mvebu_armada-37xx.h is reserved 60 bytes for fdtfile= variable. The longest value has v7-emmc variant with 51 bytes. This should be really enough.

 

Anyway, now I traced the whole init sequence again and I think I found issue in part which tries to find free buffer in environment array.

 

Would you be able to test this change if it helps? Variables are separated by one nul byte and the last variable is termined by two nul bytes.

 

diff --git a/board/Marvell/mvebu_armada-37xx/board.c b/board/Marvell/mvebu_armada-37xx/board.c
index c6ecc323bb99..73de2a3f002e 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -100,8 +100,8 @@ int board_late_init(void)
 		return 0;
 
 	/* Find free buffer in default_environment[] for new variables */
-	while (*ptr != '\0' && *(ptr+1) != '\0') ptr++;
-	ptr += 2;
+	while (*ptr != '\0' || *(ptr+1) != '\0') ptr++;
+	ptr++;
 
 	/*
 	 * Ensure that 'env default -a' does not erase permanent MAC addresses

 

Link to comment
Share on other sites

  • 0

@pali, I appreciate the attempt to fix, but as you point out, it shouldn't be happening due to reserved space.  Also, I think the environment is in a different order anyway, such that it isn't hitting the beginning of scriptaddr.  And lastly, I've been playing with u-boot 2022.10 and TF-A 2.8, and I can't repeat the problem myself.  So it may be some deeper problem that includes even the toolchain, or even something to do with starting from the older environment first.

 

We've noted that the existence of "scriptaddr" and not "criptaddr" is an important check when board fails to boot.  Better still will be to keep the platform firmware up to date so as to not have this bug at all.

 

But as for your patch: Doesn't it check each byte two times?  Do we care about efficiency?  I propose:

while (*ptr != '\0') {
  do { ptr++; } while (*ptr != '\0') ;
  ptr++;
}

The inner while will scan until the end of the current string, while the outer loop ends on the second null.  There's an initial condition of being at the end of the list already, which is detected by starting on a null rather than a character.

 

Link to comment
Share on other sites

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.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...