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

Tom Rini trini at konsulko.com
Mon Dec 9 16:49:53 CET 2019


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).

> 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.

> 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?

> 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.

> Move just DT generation to common location and keep VARs, file checking
> in board/arch scripts?

High level, this sounds right.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191209/ae9a5508/attachment.sig>


More information about the U-Boot mailing list