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

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.

Then it's not a universal image. It has to be customized to the board, because the board doesn't respect a standard that allows going to a universal image. I suppose it depends on how we define universality. My home directory can be used on multiple architectures, but ARM64 isn't gonna run on AMD64. UEFI is bytecode that's supposed to launch on any architecture, but then the kernel has to match the architecture. The UEFI apps are deconflicted by NOT using the same bits, but having separate paths for where there are necessary differences. u-boot has to match the processor, but it can then launch a universal UEFI app that can then load an architecture specific kernel. But even then, there's not a single arm64-5.19.x that carries patches for all the boards, right? I haven't. Why did this specific board discussion get tacked on to my thread about more general universality? Anyway, I might be able to try it this weekend.

@balbes150Are you writing an SD image that has u-boot for multiple rockchip processors, multiple allwinner and amlogic processors, all at the same time? This is what I mean by a universal image, and it's my understanding that putting the SPL and maybe TPL on SD causes irreconcilable conflicts between different processors.

But let's talk more generally about what is actually required, not just what is done in this instance. Otherwise, we end up with a cargo cult - we do it this way because we've always done it this way. The more "normal" we make the boot process (do it like debian or red hat, etc), the easier to support these systems with an installer rather than just flashing images to SD. What is an "ESP flag"? Bit 2 is "BIOS bootable" flag in a GPT entry, and u-boot looks for this flag as part of its autodiscovery. But there is no ESP flag - the GUID identifies the ESP on a given block device. It looks like Parted may have its own non-standard terminology here. Some of the SBCs in Armbian cannot use GPT formatted disks because vendor bootloader code is in the way. In which case, u-boot can still find EFI apps on MBR formatted disks. At the moment with stable versions of Debian, I agree with you. With systemd 251, systemd-boot improves on GRUB in a distro-agnostic way. This would enable running multiple distributions on the same block device without conflict. - If the SBC can keep u-boot with the board in flash, this is the best case, as an EFI app for the architecture ought to be automatically found and launched by u-boot. U-boot fades as a component about which to worry. - If u-boot can be loaded from eMMC hardware partition, this can work like the previous case, if the board knows how to keep its boot variables - if u-boot must be loaded from SD card, the image can never be universal, so there are only bad choices. But most of these devices need specially patched kernels anyway, so it doesn't matter how universal the bootloader is. IF u-boot provides the UEFI environment (which I think it does in most cases), then the choice of systemd-boot or GRUB or just loading the kernel directly can be made. Systemd-boot makes the most sense to me.

I really wish you'd distinguish the ESP (a FAT-formatted partition on a GPT labeled disk with the partition type of C12A7328-F81F-11D2-BA4B-00A0C93EC93B (gparted identifies this as 0xEF00) ) from "the first fat partition" which may NOT be the ESP. But if I understand what you're trying to do, you're using GRUB2 as the EFI app to then launch the linux kernel. I don't know anything about GRUB2 anymore. Certainly, it is a method of booting. But better exists.

@balbes150In the case of an UEFI booting system, I agree with you, the files necessary for boot go in the ESP (EFI System Partition) which is required to be a FAT filesystem. This is not a u-boot requirement, but a bootloader specification. https://systemd.io/BOOT_LOADER_SPECIFICATION/ . Type 1 entries have a .conf file which looks much like SYSLINUX (also EXTLINUX) format in ESP/loader/entries/. Type 2 entries are EFI applications in ESP/EFI/Linux/*.efi . Systemd-boot in Debian 12 (currently sid) can create these entries, I don't know the status in Ubuntu. For a system which is able to have firmware that goes with the board, rather than the SD card (e.g. espressobin with NAND flash), the bootloader (e.g. u-boot) can use a completely standard GPT-partitioned block device or attempt a UEFI network boot (which I know little about). For a system with eMMC, it *might* be possible to put a u-boot in place in the hardware eMMC partitions, such that it acts like the previous case, and finds the normal system on the GPT partitioned eMMC block device; but the bootloader can save its environment somewhere with the SBC. Finally, the last case is a system with no long-term storage, where even the u-boot is written to the SD card. These systems are inherently non-standard, and need workarounds like 0xEA partition on MBR or moving the GPT table entries.

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

I'm writing from a limited perspective, so constructive criticism appreciated. In this thread, I'm recording some thoughts about how the OS gets from files into the memory of various boards, and what might make this more unified and easier and/or more flexible. Current U-boot My knowledge comes from the mvebu64 and rockchip64 families. At this time, the board boot process starts from code in the processor that attempts to find u-boot, and u-boot runs a script from its environment that searches for a UEFI application or a boot.scr file. They call this "Distro-boot" Armbian uses the boot.scr to load an uncompressed kernel image and a compressed initramdisk, along with a device tree. These use u-boot legacy image format. U-boot then passes control to the kernel. On mvebu64 (espressobin), u-boot is contained within the SPI on the board, along with its environment. U-boot 2022.04 on this board can do network booting as well as searching emmc, sd, or sata devices for a boot device based on a GPT type or simply the existence of files within the first partition on each device. On rk3399, some earlier stage attempts to launch idbloader from sector 64, which loads u-boot.itb from sector 16384, from whatever device can be detected: SPI, USB, eMMC, SD. The boot.scr loads the legacy uboot images from the first partition on the device, then applies overlays - I believe this enables HATs on boards that can use them. U-boot capabilities Boot process: UEFI. U-boot can load the linux kernel through the UEFI stub, or the GRUB bootloader. As far as I can tell, it's not a drop-in replacement for a legacy kernel boot. Boot file format: Flattened uImage Tree. This is a monolithic file that has one or more of kernels, initramdisks, and device trees, along with "configurations" that can be selected to tell u-boot which files to actually load. Additionally, the components of this file can be compressed, as u-boot can uncompress the kernel before passing control. Boot media: dhcp(v6) to tftp. U-boot can attempt to boot an EFI application from tftp, before it attempts to run a script from dhcp, before it attempts to PXE boot. Extlinux script: u-boot can read /extlinux/extlinux.conf where a menu of kernels can be provided, with paths to kernel, initrd, and dtb, and an entry for the cmdline. Each kernel on the system would need to contribute a fragment of this config, which isn't currently done. Image Layout Currently, many armbian images use an MBR partition table. It's the default, and a device needs to request GPT during the build to get it. But with GPT come a few advantages. The systemd/freedesktop people seem to have a vision of a single layout that would allow a linux system to boot on several architectures, and then auto-configure based on "discoverable partitions". There are partition type uuids for such things as ARM64 root partition, or dm-verity superblock and signature partitions. These features would give a read-only, integrity checked, signed image. There are partition flags for things like "read-only" (60), "no auto" (63), or "grow-file-system" (59). Beyond this, the ESP (EFI System Partition) has a structure to allow multiple kernels/OSes to deconflict the storage of their files. Boot Sequence Type #1 Boot Loader Specification: $BOOT is the (typically) vfat partition with type "bc13c2ff-59e6-4262-a352-b275fd6f7172", or the ESP (VFAT, "c12a7328-f81f-11d2-ba4b-00a0c93ec93b"). Under $BOOT/loader/entries/, there would be files (e.g. ${machine-id}-${uname -r}-${os-release}.conf) that give configuration to find kernel and initrd at $BOOT/${machine-id}/${uname}/{linux,initrd,dtb,dtbo} Type #2: Unified kernel image - EFI PE w/ stub loader, initrd, and commandline, and can be signed cryptographically. These are at $BOOT/EFI/Linux/*.efi I assume these are handled by GRUB, as they do not seem to match u-boot's distro-boot. Armbian currently uses the boot.scr from u-boot's distroboot sequence to boot off the filesystem where boot.scr was found. First-boot and nand-sata-install When armbian builds the image, it does so through chroot and debootstrap. This results in artifacts like /etc/machine-id or /etc/ssh/ssh_host_*_key, which shouldn't be on multiple systems. They're removed as part of the image creation. Partition UUIDs ought to be changed too, but these are less likely to be a problem. The nand-sata-install attempts to create partitions to make a filesystem on some other block device, and then rsync's the running armbian system over to the new block device. It also tries to manage the u-boot bootloader and all the possible ways that can exist. (Goal) SD card partitioning sgdisk -n 14:${biosstart}:${biosend} -c 14:bios -t 14:ef02 -n 15:${uefistart}:${uefiend} -c 15:efi -t 15:ef00 -n 1:${rootstart}:0 -c 1:root -t 1:8305 -A 1:set:59 ${SDCARD}.raw This produces a GPT-formatted disk with the first partition (numbered 14) with a BIOS type (recommended 1 mb, or covering u-boot and files), an ESP (recommended 550 MB, to mount on /efi/), and an auto-detected ARM64 root partition that is labeled to grow to fill the disk when booted. Linux should be stored in a UEFI or FIT image, preferably as a UEFI boot method. U-boot environment variables for a given board should be able to select the appropriate armbian kernel, allowing the root filesystem to have multiple kernels for different boards installed and an SD card that boots on multiple boards.