Hi Marc,
On 6/9/25 6:40 PM, Marc Haber wrote:
[You don't often get email from mh+u-b...@zugschlus.de. Learn why this
is important at https://aka.ms/LearnAboutSenderIdentification ]
Hi,
for flexibility reasons I want to use u-boot to boot Debian on a
Raspberry Pi 4. I want to be able to fix a broken boot from remote over
the serial console. I have therefore written a boot.scr script that
looks for kernel and initrd on various partitions on various media in
various directories, loads kernel, initrd and devicetree and boots.
I am using the uboot binary that comes with Debian's u-boot-rpi:arm64
2025.01-3 package. That one is configured like that:
CONFIG_ENV_IS_IN_FAT=y
CONFIG_ENV_FAT_INTERFACE="mmc"
CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
CONFIG_ENV_FAT_FILE="uboot.env"
This works as long as I am booting from an MMC card: The Raspi Firmware
reads config.txt (from MMC), loads uboot.bin (from MMC), which in turn
reads uboot.env and boot.scr (from MMC), the script runs and the system
comes up. While this happens, u-boot talks to me on the serial console,
presumably because uboot.env contains variables like
baudrate=115200
stderr=serial,vidconsole
stdin=serial,usbkbd
stdout=serial,vidconsole
However, when I have everything on USB, things don't work as smoothly.
The system does not come up and it doesn't talk to me on the serial
console. What I guess is that the Raspi Firmware reads config.txt (from
USB), loads uboot.bin (from USB) which then looks on the non-existent
MMC device for uboot.env and boot.scr. Game Over.
Is it somehow possible to have u-boot look for uboot.env and/or boot.scr
on the same device it was booted from? Can I compile in some kind of
search order so that u-boot can find uboot.env and boot.scr on other
devices than the first partition on mmc? Or do I really need to build my
own u-boot.bin?
On Theobroma boards (Rockchip-based), we force the environment to be
coming from the same storage medium as U-Boot proper, c.f.
board/theobroma-systems/common/common.c:arch_env_get_location()
This is the location of the U-Boot environment in raw, not in a
filesystem, so this won't apply to your use-case.
But quickly looking at env/fat.c which makes use of the CONFIG_ENV_FAT*
variables from above, it seems like you should be able to override
env_fat_get_intf and env_fat_get_dev_part from a board file and
implement what you want there, provided U-Boot (and/or the RPi firmware)
provides you with the information from where it was booted.
If you don't want to change the U-Boot binary and somehow you can have a
minimal environment to run a few commands, you could probably erase the
whole environment and re-import it manually with `env import`?
Cheers,
Quentin
