CONFIG_SYS_SPL_ARGS_ADDR

CONFIG_SYS_SPL_ARGS_ADDR

[Sven Schwermer]

Hi,

I'm looking into booting Linux FIT images from SPL. In board_init_r 
(common/spl/spl.c), the boot argument is set to CONFIG_SYS_SPL_ARGS_ADDR 
if defined. When booting a FIT image including a DTB, shouldn't this 
automatically be set to fdt_addr (struct spl_image_info)? This would 
ensure a single point of truth for the DTB address (load address as 
encoded in the FIT image or DTB data start location within the FIT blob 
if no load address is defined) instead of having to set 
CONFIG_SYS_SPL_ARGS_ADDR to the DTB load address.

I'm not sure whether I'm interpreting this correctly. It would be nice 
if somebody could give some advice.

Best regards,
Sven

Re: CONFIG_SYS_SPL_ARGS_ADDR

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

On Sat, Jan 01, 2022 at 08:00:45PM +0100, Sven Schwermer wrote:

> Hi,
> 
> I'm looking into booting Linux FIT images from SPL. In board_init_r
> (common/spl/spl.c), the boot argument is set to CONFIG_SYS_SPL_ARGS_ADDR if
> defined. When booting a FIT image including a DTB, shouldn't this
> automatically be set to fdt_addr (struct spl_image_info)? This would ensure
> a single point of truth for the DTB address (load address as encoded in the
> FIT image or DTB data start location within the FIT blob if no load address
> is defined) instead of having to set CONFIG_SYS_SPL_ARGS_ADDR to the DTB
> load address.
> 
> I'm not sure whether I'm interpreting this correctly. It would be nice if
> somebody could give some advice.

So, the issue is that we don't enforce environment variables existing
(typically).  The falcon mode code also predates the distro boot stuff
that brought us more consistency in fdt related variable naming and
usage.  Cleanups to the falcon code to make use of this newer code would
be appreciated.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: CONFIG_SYS_SPL_ARGS_ADDR

[Sven Schwermer]

Hi Tom,

I think you have have misunderstood me. I meant fdt_addr, the member of 
struct spl_image_info, not an environment variable with that name. Does 
that make sense?

Best regards,
Sven

On 1/11/22 17:17, Tom Rini wrote:
> On Sat, Jan 01, 2022 at 08:00:45PM +0100, Sven Schwermer wrote:
> 
>> Hi,
>>
>> I'm looking into booting Linux FIT images from SPL. In board_init_r
>> (common/spl/spl.c), the boot argument is set to CONFIG_SYS_SPL_ARGS_ADDR if
>> defined. When booting a FIT image including a DTB, shouldn't this
>> automatically be set to fdt_addr (struct spl_image_info)? This would ensure
>> a single point of truth for the DTB address (load address as encoded in the
>> FIT image or DTB data start location within the FIT blob if no load address
>> is defined) instead of having to set CONFIG_SYS_SPL_ARGS_ADDR to the DTB
>> load address.
>>
>> I'm not sure whether I'm interpreting this correctly. It would be nice if
>> somebody could give some advice.
> 
> So, the issue is that we don't enforce environment variables existing
> (typically).  The falcon mode code also predates the distro boot stuff
> that brought us more consistency in fdt related variable naming and
> usage.  Cleanups to the falcon code to make use of this newer code would
> be appreciated.
>