[PATCH v2] arm64: zynqmp: Add support for u-boot.itb generation with ATF

[Michal Simek]

On 09. 12. 19 16:49, Tom Rini wrote:
> On Mon, Dec 09, 2019 at 03:21:02PM +0100, Michal Simek wrote:
>> On 05. 12. 19 15:33, Tom Rini wrote:
>>> On Thu, Dec 05, 2019 at 09:46:57AM +0100, Michal Simek wrote:
>>>> Follow i.MX, Sunxi, RISC-V and Rockchip to generate u-boot.itb which
>>>> includes U-Boot proper, ATF and DTBs in FIT format. ZynqMP supports FIT for
>>>> quite a long time but with using out of tree solution. The patch is filling
>>>> this gap.
>>>>
>>>> Tested on zcu102, zcu104 and zcu100/Ultra96.
>>>>
>>>> zcu100/Ultra96 v2.2 ATF build by:
>>>> make DEBUG=0 ZYNQMP_CONSOLE=cadence1 RESET_TO_BL31=1 PLAT=zynqmp bl31
>>>>
>>>> Signed-off-by: Michal Simek <michal.simek at xilinx.com>
>>>> ---
>>>>
>>>> Changes in v2:
>>>> - Exchange u-boot/atf in config section
>>>> - Use default ATF baseaddr from mainline
>>>> - Update commit message
>>>>
>>>>  Kconfig                                 |  3 +-
>>>>  arch/arm/mach-zynqmp/mkimage_fit_atf.sh | 99 +++++++++++++++++++++++++
>>>
>>> My only complaint here is adding and N'th version of mkimage_fit_atf.sh
>>> that varies seemingly only in addresses.  Can we not abstract this
>>> enough to make it for everyone to use and pass in the needed values?
>>
>> First of all I will be sending v3 because of other things I found.
>>
>> Adding more folks to this.
>>
>> I have went through all versions and here is sort of stat:
>>
>> board/sunxi/mksunxi_fit_atf.sh - firmware is uboot, atf loadables (not
>> standard)
>>
>> board/theobroma-systems/puma_rk3399/fit_spl_atf.sh - license present
>> atf, uboot, pmufw (only present here)
>>
>> arch/arm/mach-rockchip/make_fit_atf.py - python (only one) and read
>> addresses from elfs
>>
>> arch/arm/mach-rockchip/fit_spl_optee.sh - firmware is tee(no ATF)
>>
>> arch/riscv/lib/mkimage_fit_opensbi.sh - reads stuff from .config and
>> also handles non DT case
>>
>> arch/arm/mach-imx/mkimage_fit_atf.sh - optee, atf, incorrect dt nodes names
>>
>> And of course this one.
> 
> Thanks for looking more here.
> 
>> -------------------------------
>>
>> I think the key point here is to start talk about how this should be done.
>> Language? One is python others are shell scripts.
> 
> I don't have a hard preference here.  I think the reason we have one in
> Python is for ease of working with ELF.  Restrictions / issues like that
> probably mean it would be best to make sure we pick a language that
> allows for peeking at ELFs but I have not confirmed if we could easily
> re-do the rockchip python tool in shell by using a standard tool
> (objdump or similar from binutils, so we'll certainly have it).


I expect that all addresses are just entry points of these elfs
It means something like this should be enough.
readelf -l bl31.elf | awk '/Entry point/ { print $3 }'

> 
>> Should it stop when ATF/TEE is not found?
> 
> For CI it must non-fatally complete, but should also be verbose in that
> the resulting binary is non-functional.

ok.

> 
>> What file to read to get information from u-boot? .config or
>> include/generated/autoconf.h?
> 
> Honestly?  I'd like to start looking at something better if we can here
> as these are not really user-configurable values, but system values.
> Some property under a -u-boot.dtsi file?

I still have one ancient branch to get rid of all u-boot,dm* variables
from nodes and move them to chosen node where they should be.
Can you please elaborate on this more?


>> Read information about locations from ELFs?
>>
>> Should we handle non DT case? Yes?
> 
> Sorry, non-DT case in this instance meaning what?  We're talking about
> FIT and FIT uses a DT.

With OF_BOARD configurations where DT can be stored somewhere else there
could be use cases that you want to have FIT without DT.


>> Move just DT generation to common location and keep VARs, file checking
>> in board/arch scripts?
> 
> High level, this sounds right.  Thanks!

I would like to get more feedback from others to agreed how this should
be done before anybody invest time for doing it.

Thanks,
Michal