ManoftheSea Posted April 13, 2022 Posted April 13, 2022 https://github.com/armbian/build/pull/3675 0 Quote
Pali Posted April 13, 2022 Posted April 13, 2022 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. 0 Quote
lampra Posted April 13, 2022 Posted April 13, 2022 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. 0 Quote
Heisath Posted April 13, 2022 Posted April 13, 2022 5 minutes ago, lampra said: To my understanding, these firmware files would need to be rebuilt based on the mainline TFA and uboot. https://github.com/armbian/build/pull/3498 0 Quote
lampra Posted April 13, 2022 Posted April 13, 2022 5 minutes ago, Heisath said: https://github.com/armbian/build/pull/3498 Thank you, then it is only a mater of availability in the download page for the moment. 0 Quote
ManoftheSea Posted April 14, 2022 Posted April 14, 2022 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. 0 Quote
Pali Posted April 14, 2022 Posted April 14, 2022 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. 0 Quote
ManoftheSea Posted April 14, 2022 Posted April 14, 2022 1 hour ago, Pali said: I always have correct scriptaddr I wouldn't have believed myself if I hadn't seen it and tried it a few times. Well, I'll re-flash the latest u-boot and see if there's a change. 2022.04, right? 0 Quote
Pali Posted April 14, 2022 Posted April 14, 2022 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. 1 Quote
ManoftheSea Posted April 15, 2022 Posted April 15, 2022 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. 0 Quote
ManoftheSea Posted April 15, 2022 Posted April 15, 2022 @PaliHow does u-boot know or look up the appropriate memory location to load the kernel, ramdisk, dtb? If I have an espressobin_kernel.itb, is it correct to load it at $ramdisk_addr_r (which I show as 0xa000000, it used to be 0x8000000). Thanks for your help. 0 Quote
Pali Posted April 21, 2022 Posted April 21, 2022 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. 1 Quote
ManoftheSea Posted April 22, 2022 Posted April 22, 2022 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 ... 0 Quote
Pali Posted April 22, 2022 Posted April 22, 2022 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? 0 Quote
ManoftheSea Posted April 22, 2022 Posted April 22, 2022 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. 0 Quote
Pali Posted April 22, 2022 Posted April 22, 2022 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 1 Quote
ManoftheSea Posted May 2, 2022 Posted May 2, 2022 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. 0 Quote
ManoftheSea Posted May 8, 2022 Posted May 8, 2022 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. 1 Quote
ABF023 Posted November 9, 2022 Posted November 9, 2022 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~ 0 Quote
Pali Posted November 9, 2022 Posted November 9, 2022 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?). 0 Quote
ABF023 Posted November 9, 2022 Posted November 9, 2022 Seems that you have broken /boot/boot.scr script on mmc 0:1 device (SD card?). On the SDcard is the latest Armbian 22.08 Bullseye ， How do I fix this error? Please give me a hint... 0 Quote
Pali Posted November 9, 2022 Posted November 9, 2022 You need to debug it why it cannot load required file. Probably file does not exist or there is an error on that load line in that script. 0 Quote
ABF023 Posted November 9, 2022 Posted November 9, 2022 Thanks for replying, how do I enter debug mode? 23 minutes ago, Pali said: You need to debug it why it cannot load required file. Probably file does not exist or there is an error on that load line in that script. 0 Quote
ABF023 Posted November 9, 2022 Posted November 9, 2022 Is this problem the cause of u-boot or Armbian 22.08 Bullseye? Thank you~ 0 Quote
ManoftheSea Posted November 9, 2022 Posted November 9, 2022 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. 0 Quote
ABF023 Posted November 10, 2022 Posted November 10, 2022 (edited) Thank you very much. The printenv information is as follows: Edited November 10, 2022 by armbianfans023 0 Quote
ManoftheSea Posted November 11, 2022 Posted November 11, 2022 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. 0 Quote
Pali Posted November 11, 2022 Posted November 11, 2022 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. 0 Quote
ManoftheSea Posted November 25, 2022 Posted November 25, 2022 @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") 0 Quote
Pali Posted November 26, 2022 Posted November 26, 2022 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 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.