[PATCH 2/3] mksunxi_fit_atf.sh: Update FIT component descriptions

[Patrick Wildt <patrick@blueri.se>]

On Sat, May 09, 2020 at 02:02:19PM -0500, Samuel Holland wrote:
> On 5/8/20 4:45 AM, Patrick Wildt wrote:
> > Hi,
> > 
> > now this really confuses me.
> > 
> > commit 0db0ba6141f402b1d496ef53d9fa69978f75ec61 has explicitly made
> > u-boot the firmware and moved atf into the loadables on NXP i.MX.
> > Here you do the complete opposite for sunxi.
> > 
> > Can people please make up their minds how it is *supposed* to work?
> 
> I don't think that commit is suggesting how things are supposed to work; it's a
> workaround responding to the existing limitations in SPL_FIT_IMAGE_TINY.
> Specifically, that "firmware" is assumed to be U-Boot, and "loadables" are
> assumed to be something else.
> 
> The first patch in this series removes those limitations by actually looking at
> the "os" property. With my first patch applied, U-Boot would be detected in
> either list, so booting would work with or without commit 0db0ba6141f4.
> 
> So for the reasons I outline below (the functionality of the "switch
> (spl_image.os)" in board_init_r), it might make sense to revert that commit
> after applying this series.
> 
> Cheers,
> Samuel

I tend to agree.  Having ATF as a "firmware", spl_load_simple_fit()
would with your diff actually recognize that it's ATF and not U-Boot, so
it wouldn't append the FDT.  Then it goes over the loadables.  Loads
U-Boot, sees it is U-Boot, appends the FDT, and then (possibly) OP-TEE.

I'm still not sure what should be "firmware" and what "loadables", but
if ATF is supposed to be "firmware", your diff makes sense and it would
make sense to revert the change in the i.MX mkimage script.

So in that case I'd say:

Acked-by: Patrick Wildt <patrick@blueri.se>

Best regards,
Patrick