Hi Marc,
On 6/10/25 12:50 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 Quentin,
thanks for answering. I really appreciate that.
On Tue, Jun 10, 2025 at 12:36:23PM +0200, Quentin Schulz wrote:
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.
Sadly ;-)
But the logic to detect which boot medium was used is there, hence why I
mentioned it :)
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.
Can I get u-boot to somehow log where it is looking for files? That way
I wouldn't have to guess where to put a board file.
By "board file" i meant a C file in board/ (for RPi, typically
board/raspberrypi/rpi/ I woudl assume).
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`?
As far as I have understood, if u-boot finds neither its environment
file or a boot.scr (that one comes from the environment as well, right?)
it just sits there doing nothing. It's that first step that I don't
understand.
Which first step are you talking about?
Cheers,
Quentin
