ManoftheSea

@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.

@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")

I was able to boot from a SATA disk that was manually setup with a GPT-formatted table and a debootstrap'ed debian arm64 kernel. The GPT partitions included: 1. BIOS from sector 34-2047, no filesystem 2. ESP from 2048-409599 (which u-boot calls bootable even if the flag isn't set), vfat filesystem 3. XBOOTLDR from 409600-819199 with bootable flag set (0x4), ext4 FS without journal 4. linux swap 5. ARM64 root (gdisk type 8305) with bit 60 set (read-only), ext4 without journal 6. linux /var (gdisk type 8310), ext4, with /srv/ and /home/ bind-mounted from /var/local/ The bootscripts/extlinux configuration live in /boot, onto which is mounted partition 3 (XBOOTLDR) next to the actual kernel/initramdisk. It is necessary to mark this partition bootable in gdisk to have the u-boot distro-boot search it for extlinux/boot.scr. While the espressobin doesn't require u-boot flashed on the boot media, this disk partition scheme would allow rockchip64 systems to boot if the BIOS partition is extended to somewhere around sector 32767 (as rockchip needs code at sector 64 and maybe 16384 and 24576).