[PATCH v1] ti: k3: abstract common fdt api for reserved mem fixups
Anshul Dalal
anshuld at ti.com
Thu Jun 5 06:05:53 CEST 2025
On Wed Jun 4, 2025 at 11:27 PM IST, Tom Rini wrote:
> On Thu, May 22, 2025 at 08:39:40PM +0530, Anshul Dalal wrote:
>
>> The usage of fdt_fixup_reserved is repeated for ATF and OP-TEE for
>> multiple platforms, this patch creates a single fdt API for fixing up
>> the reserved-memory node with added error handling.
>>
>> All k3 platforms already share a common tispl template which ensures
>> binaries are loaded as per the respective CONFIG_*_LOAD_ADDR. And the
>> provided new_size for the fixup is overridden by the size from fdt node
>> anyways. This allows for safe abstraction of the reserved memory fixups
>> for all current platforms.
>>
>> fdt_fixup_reserved now abstracts the ATF and OP-TEE fixups by calling
>> the renamed static fdt_fixup_reserved_memory function with the required
>> parameters.
>>
>> Signed-off-by: Anshul Dalal <anshuld at ti.com>
> [snip]
>
> I think this shows the start of fixing up some problems, but that we
> need to do more.
>
>> diff --git a/arch/arm/mach-k3/am62ax/am62a7_fdt.c b/arch/arm/mach-k3/am62ax/am62a7_fdt.c
>> index 7f764ab36b5..9a4599432ff 100644
>> --- a/arch/arm/mach-k3/am62ax/am62a7_fdt.c
>> +++ b/arch/arm/mach-k3/am62ax/am62a7_fdt.c
>> @@ -10,8 +10,5 @@
>>
>> int ft_system_setup(void *blob, struct bd_info *bd)
>> {
>> - fdt_fixup_reserved(blob, "tfa", CONFIG_K3_ATF_LOAD_ADDR, 0x80000);
>> - fdt_fixup_reserved(blob, "optee", CONFIG_K3_OPTEE_LOAD_ADDR, 0x1800000);
>> -
>> - return 0;
>> + return fdt_fixup_reserved(blob);
>> }
>
> This is good.
>
>> diff --git a/arch/arm/mach-k3/am62px/am62p5_fdt.c b/arch/arm/mach-k3/am62px/am62p5_fdt.c
>> index 2c40fa5a594..9f4b1663864 100644
>> --- a/arch/arm/mach-k3/am62px/am62p5_fdt.c
>> +++ b/arch/arm/mach-k3/am62px/am62p5_fdt.c
>> @@ -92,8 +92,5 @@ int ft_system_setup(void *blob, struct bd_info *bd)
>> fdt_fixup_canfd_nodes_am62p(blob, k3_has_canfd());
>> fdt_fixup_thermal_zone_nodes_am62p(blob, k3_get_max_temp());
>> fdt_fixup_cpu_freq_nodes_am62p(blob, k3_get_a53_max_frequency());
>
> Is it really OK for any of the above fixups to fail to happen and be
> silently ignored? fdt_fixup_thermal_zone_nodes_am62p() for example looks
> like it throws away error conditions from functions it calls. And other
> boards are doing similar things.
>
Yeah, all fdt_fixup_* currently don't propogate the errors to the caller
(ft_system_setup). I will refactor the fdt_fixup_* functions to return
errors instead, we can then decide in ft_system_setup whether to ignore
them with a warning log or fail booting by propogating the error
upwards.
[snip]
>> + ret = fdt_fixup_reserved_memory(blob, "optee",
>> + CONFIG_K3_OPTEE_LOAD_ADDR, 0x1800000);
>> + if (ret)
>> + return ret;
>> +
>> + return 0;
>
> But we can just return fdt_fixup_reserved_memory(...) here.
You're right, will be fixed in the next revision.
Thanks for the review Tom,
Anshul
More information about the U-Boot
mailing list