[PATCH] configs: ti: use standard configuration nodes naming

[Romain Naour]

Hi Denys,

Le 28/02/2022 à 21:38, Denys Dmytriyenko a écrit :
> On Thu, Feb 10, 2022 at 11:13:36PM +0100, Romain Naour wrote:
>> Currently, any u-boot bootloader for ti armv7 platforms using
>> DEFAULT_FIT_TI_ARGS to boot with a fitimage (boot_fit = 1)
>> doesn't boot when built with Yocto Poky (openembedded-core).
>>
>>   ## Loading kernel from FIT Image at 90000000 ...
>>   Could not find configuration node
>>   ERROR: can't get kernel image!
>>
>> Arago forked the kernel-fitimage class [1] and altered the
>> configuration nodes naming while adding the OPTEE support by
>> using FITIMAGE_CONF_BY_NAME by default [2].
>>
>> The "upstream" kernel-fitimage class from openembedded-core still
>> add the "conf-" prefix for each configuration nodes [3].
>>
>> The ITS file format (from doc/uImage.FIT/source_file_format.txt)
>> is not really accurate with the expected naming of these nodes.
>> But in practice the "conf-" prefix is widely used.
>>
>> When the FIT image support has been added for ti armv7 platforms
>> the naming from Arago has been used [3]. Fix this issue by adding
>> the prefix expected by the ITS file generated by kernel-fitimage
>> class from openembedded-core.
> 
> Well, this is a bit more complicated and convoluted, than what you 
> explained here...

I did my best to explain the issue I had and justify why the patch should be
applied to u-boot mainline.

> 
> [with my Arago/downstream hat on]
> 
> Arago forked kernel-fitimage class long time ago to add support for TI 
> ARMv7 HS (High Secure) devices, which used some custom ways of signing 
> and handling images. Unfortunately, kernel-fitimage class in OE-Core 
> was and is not that flexible or easily extendable, hence the fork.
> 
> Back then OE-Core was using numbered nodes "fdt@<num>" in the FIT image, 
> while Arago switched to using named nodes. As you correctly mentioned, 
> there's actually no defined standard on naming those nodes in ITS. 
> Moreover, OE-Core changed its way few times, until coming to the 
> current naming scheme with "conf-" prefix.
> 
> Since Arago fork of kernel-fitimage class was heavily customized, it 
> fell behind and wasn't updated with more recent changes in OE-Core.
> 
> Unlike "legacy" TI HS devices of ARMv7 architecture, TI K3 HS devices 
> of Aarch64 architecture are fully standard with open tooling. To that 
> extent, I made a recent change to use upstream kernel-fitimage class 
> from OE-Core:
> 
> https://git.yoctoproject.org/meta-arago/commit/?id=ae07d01dc54f84a88c479d0aaad8c5fa110182eb

Ok, thanks for the explanation!

> 
> 
> [with my OpenEmbedded/upstream hat on]
> 
> I support this change in U-boot, which means Arago/TI-SDK will have to 
> adjust once it catches up with the latest version of U-boot.

Agree.

> 
> 
>> [1] http://arago-project.org/git/meta-arago.git?p=meta-arago.git;a=commitdiff;h=719ab1b2098bcdc59c249e3529fa82cb1b9130e6
>> [2] http://arago-project.org/git/meta-arago.git?p=meta-arago.git;a=commitdiff;h=f23f2876a0cda89241d031bb7ba0b4256ed90035
>> [3] https://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass?h=yocto-3.1.13#n290
>> [3] 1e93cc8473e4fe018aececc8ed3bf8fc2b3ff561
>>
>> Signed-off-by: Romain Naour <romain.naour at smile.fr>
>> Cc: Tom Rini <trini at konsulko.com>
> 
> Reviewed-by: Denys Dmytriyenko <denys at konsulko.com>

Do you need I repin the patch including your reply ?

Best regards,
Romain

> 
> 
>> ---
>>  include/configs/ti_armv7_common.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h
>> index 9733707009..7483bc821d 100644
>> --- a/include/configs/ti_armv7_common.h
>> +++ b/include/configs/ti_armv7_common.h
>> @@ -55,7 +55,7 @@
>>  		"do;" \
>>  		"setenv overlaystring ${overlaystring}'#'${overlay};" \
>>  		"done;\0" \
>> -	"run_fit=bootm ${addr_fit}#${fdtfile}${overlaystring}\0" \
>> +	"run_fit=bootm ${addr_fit}#conf-${fdtfile}${overlaystring}\0" \
>>  
>>  /*
>>   * DDR information.  If the CONFIG_NR_DRAM_BANKS is not defined,
>