On 9/17/25 16:25, Quentin Schulz wrote:
> Hi Köry,
>
> On 9/17/25 4:17 PM, Kory Maincent wrote:
>> This reverts commit d37641c61ba212241c38e3fd22f0335fc0bebc96.
>>
>> Restore support for environment storage in EXT4 filesystem on eMMC boot.
>> The previous cleanup incorrectly removed this fallback option which is
>> needed for boards that store their environment in an EXT4 partition.
>>
>> This configuration is OS-specific rather than board-dependent and should
>> remain as it is configurable via menuconfig. Even if it is not described
>> in ST defconfigs people may have enabled it in their defconfig.
>>
>> Signed-off-by: Kory Maincent <kory.mainc...@bootlin.com>
>> ---
>>
>> Debugging this issue raises another issue that need investigation.
>> If env_get_location return ENVL_IS_NOWHERE but CONFIG_ENV_IS_NOWHERE is
>> not set, U-boot stall without any log. There might be an ENV check issue
>> here.
>
> I believe this may be related to what I hit almost three years ago, see
> commit log in
> https://source.denx.de/u-boot/u-boot/-/commit/b1f1b4a5a528eeefea283ccca2ee9777cb10c840
>
> """
> since arch_env_get_location() is called
> by env_init() which is part of the pre-relocation process, a valid,
> non-ENVL_UNKNOWN, value shall be returned otherwise the relocation fails
> with the following message:
> initcall sequence 00000000002866c0 failed at call 0000000000256b34 (err=-19)
>
> This valid, non-ENVL_UNKNOWN, value is ENVL_NOWHERE which requires to
> always select CONFIG_ENV_IS_NOWHERE otherwise this work-around does not
> work.
> """
>
> Hope this helps.
>
> I haven't dug deeper than that though.
>
> Cheers,
> Quentin
Hi
On reason is enum env_location are all defined in include/env_internal.h
regardless
CONFI_ENV_IS_IN_XXX flags being enabled.
So env_get_location() can return ENVL_NOWHERE without ENV_IS_NOWHERE flag set.
which can lead to issue described by Quentin just above.
Patrice
