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.si...@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
signature.asc
Description: PGP signature