Searching and Finding boot.scr and uboot.env on a Raspberry Pi 4

[Quentin Schulz]

Hi Marc,

On 6/10/25 12:50 PM, Marc Haber wrote:
> [You don't often get email from mh+u-boot at 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