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

[Tom Rini]

On Tue, Dec 10, 2019 at 01:03:29PM +0100, Michal Simek wrote:
> 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 }'

OK.  Then we should probably stick to shell.

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

Well, it's been pointed out before, and I agree, that a lot of things we
have had historically in CONFIG_xxx symbols are things that just aren't
appropriate for Kconfig (users shouldn't change them, putting N default
values in Kconfig is ugly, etc).  While devicetree-the-in-kernel-file is
to describe the hardware, devicetree-the-syntax is something we use for
other things (FIT images) and other projects take even farther.  So I've
been thinking that devicetree-the-syntax seems like a good way to handle
this particular problem.  Where it all goes, I don't know.

-- 
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/20191210/1a185424/attachment.sig>