[RFC PATCH] zynqmp: Add binman description for SOM

[Simon Glass]

Hi Michal,

On Mon, 4 Nov 2024 at 01:32, Michal Simek <michal.simek at amd.com> wrote:
>
> Hi Simon,
>
> On 11/2/24 17:28, Simon Glass wrote:
> > Hi Michal,
> >
> > On Fri, 1 Nov 2024 at 14:52, Tom Rini <trini at konsulko.com> wrote:
> >>
> >> On Fri, Nov 01, 2024 at 02:09:38PM +0100, Michal Simek wrote:
> >>> Hi Simon,
> >>>
> >>> On 11/1/24 09:27, Michal Simek wrote:
> >>>>
> >>>>
> >>>> On 10/31/24 19:03, Simon Glass wrote:
> >>>>> Hi Michal,
> >>>>>
> >>>>> On Wed, 9 Oct 2024 at 10:33, Michal Simek <michal.simek at amd.com> wrote:
> >>>>>>
> >>>>>> There is necessary to do some steps to compose boot images. These steps
> >>>>>> were in scripts in layers for a while. That's why introduce description via
> >>>>>> binman to simplify wiring and remove all scripting around.
> >>>>>> This should make sure that everybody is up2date with the latest versions.
> >>>>>>
> >>>>>> The first step is to create fit image with DTBs with descriptions in
> >>>>>> configuration node which is written as regular expression to match all SOM
> >>>>>> versions.
> >>>>>> Description is there for k24 and k26 in spite of low level psu_init
> >>>>>> configuration is different. The reason is that it goes to u-boot.itb image
> >>>>>> which is the same for k24 and k26.
> >>>>>> u-boot.itb is another image which is generated. It is normally generated
> >>>>>> via arch/arm/mach-zynqmp/mkimage_fit_atf.sh but this script is supposed to
> >>>>>> be deprecated.
> >>>>>> FIT image by purpose is using 64bit addresses to have default option to
> >>>>>> move images to high DDR (above 4GB). TF-A and TEE are optional components
> >>>>>> but in the most cases TF-A is present all the time and TEE(OP-TEE) is used
> >>>>>> by some configurations too.
> >>>>>>
> >>>>>> 3rd generated image is boot.bin with updated user field which contains
> >>>>>> version number. This image can be used with updated Image Selector
> >>>>>> which supports A/B update mechanisms with rollback protection.
> >>>>>>
> >>>>>> 4th image is image.bin which binary file which contains boot.bin and
> >>>>>> u-boot.itb together and can be programmed via origin Image Selector.
> >>>>>> This image can be also used for creating one capsule which contains both
> >>>>>> boot images (in SPL boot flow).
> >>>>>>
> >>>>>> Signed-off-by: Michal Simek <michal.simek at amd.com>
> >>>>>> ---
> >>>>>>
> >>>>>> Currently I have this for testing purpose only to find missing bits and
> >>>>>> pieces in binman for cases I want to support.
> >>>>>>
> >>>>>> This patch depends on
> >>>>>> https://lore.kernel.org/r/ fbed0251437b61a2f7a85596d7403b5b9c8237c1.1728306322.git.michal.simek at amd.com
> >>>>>>
> >>>>>> ---
> >>>>>>    arch/arm/dts/Makefile                |   1 +
> >>>>>>    arch/arm/dts/zynqmp-som-binman.dts   | 224 +++++++++++++++++++++++++++
> >>>>>>    arch/arm/mach-zynqmp/Kconfig         |  17 ++
> >>>>>>    configs/xilinx_zynqmp_kria_defconfig |   2 +
> >>>>>>    4 files changed, 244 insertions(+)
> >>>>>>    create mode 100644 arch/arm/dts/zynqmp-som-binman.dts
> >>>>>
> >>>>> I'm pleased to see this. My only suggestion is to use '/bits/ 64'
> >>>>> instead of the macros, for 64-bit values.
> >>>>
> >>>> When I was playing with it some time ago it didn't work but it works now
> >>>> that's why no issue with it.
> >>>
> >>> One more thing on this one. I pretty much dislike that images are generated
> >>> to u-boot root folder. Isn't there a way that they will be written to
> >>> separate folder (deploy for example)?
> >>
> >> Or perhaps $(obj) ?
> >
> > Yes $(obj) is where they end up today. I consider output files from
> > binman to be on the same level as other files created by the build.
> > Then again, it does end up a bit of a mess, when mixed with the output
> > files.
>
> Some cleanup would be good. I remember a lot of discussion about if people
> should be using u-boot or u-boot.elf. Answer was simple but if output images are
> in separate folder it would IMHO better to understand.
>
> > I am not keen on 'deploy' as it nothing is being deployed - also it
> > sounds like a satellite or military attack.
>
> No problem with different name.
>
> >
> > One long-standing issue is that intermediate files are created in the
> > same directory. Perhaps we could put those in a binman-tmp directory?
> > They are necessary when things go wrong, but don't need to be used all
> > the time.
>
> +1
>
> But I think we should try to move also that images which users should be using
> to separate folder completely. Again it doesn't need to be done by default but a
> way to configure it would be good.

Perhaps file an issue for this? I haven't got to it yet.

Regards,
Simon