[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPnjgZ1e4cryN=Q8XufrdEcJoHfW5n-aN-F3pr2mTWA_0c5-Gg@mail.gmail.com>
Date: Wed, 29 Nov 2023 12:00:59 -0700
From: Simon Glass <sjg@...omium.org>
To: Ahmad Fatoum <a.fatoum@...gutronix.de>
Cc: linux-arm-kernel@...ts.infradead.org,
Masahiro Yamada <masahiroy@...nel.org>,
Tom Rini <trini@...sulko.com>,
lkml <linux-kernel@...r.kernel.org>,
U-Boot Mailing List <u-boot@...ts.denx.de>,
Catalin Marinas <catalin.marinas@....com>,
Nathan Chancellor <nathan@...nel.org>,
Nick Terrell <terrelln@...com>,
Nicolas Schier <nicolas@...sle.eu>,
Will Deacon <will@...nel.org>, linux-kbuild@...r.kernel.org,
Pengutronix Kernel Team <kernel@...gutronix.de>
Subject: Re: [PATCH v7 2/2] arm64: boot: Support Flat Image Tree
Hi Ahmad,
On Wed, 29 Nov 2023 at 11:35, Ahmad Fatoum <a.fatoum@...gutronix.de> wrote:
>
> Hello Simon,
>
> On 29.11.23 18:21, Simon Glass wrote:
> > Add a script which produces a Flat Image Tree (FIT), a single file
> > containing the built kernel and associated devicetree files.
> > Compression defaults to gzip which gives a good balance of size and
> > performance.
>
> Thanks for working on this. I think it's useful to have the kernel
> generate a FIT image out of the box. More complex use cases are always
> free to call mkimage with a custom ITS.
>
>
> > The files compress from about 86MB to 24MB using this approach.
> >
> > The FIT can be used by bootloaders which support it, such as U-Boot
> > and Linuxboot. It permits automatic selection of the correct
> > devicetree, matching the compatible string of the running board with
> > the closest compatible string in the FIT. There is no need for
> > filenames or other workarounds.
> >
> > Add a 'make image.fit' build target for arm64, as well.
>
> not that it matters much, but should this maybe called Image.fit
> as the other Image types are capitalized too?
>
> > EFI_ZBOOT_PAYLOAD := Image
> > EFI_ZBOOT_BFD_TARGET := elf64-littleaarch64
> > EFI_ZBOOT_MACH_TYPE := ARM64
> > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> > index 1a965fe68e01..e1c06ca3c847 100644
> > --- a/scripts/Makefile.lib
> > +++ b/scripts/Makefile.lib
> > @@ -496,6 +496,19 @@ quiet_cmd_uimage = UIMAGE $@
> > -a $(UIMAGE_LOADADDR) -e $(UIMAGE_ENTRYADDR) \
> > -n '$(UIMAGE_NAME)' -d $< $@
>
> Doesn't hardcoding a load address and entry address here defeat the point
> of having FIT as generic portable image format?
>
> At least barebox will try to place the kernel image at physical address 0 and
> will exit with an error message if no SDRAM is located at that address.
> The recommendation in that case is to omit load and entry address altogether
> to have barebox find a suitable location, but I see now that the FIT specification
> requires a load and entry address. What would happen if U-Boot tries to load this
> FIT image on a board that has no DRAM at address 0?
The 'kernel_noload' type indicates that the load/exec address are ignored.
>
> Please Cc me on subsequent revisions. I am interested in testing that this works for barebox
> too.
There has been some discussion about this recently in U-Boot too,
along with a series [1] which you could try if you like.
The FIT spec[2] does not provide enough detail on exactly what
kernel_noload means and we should improve this at some point.
Regards,
Simon
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=382849
[2] https://github.com/open-source-firmware/flat-image-tree
>
> Thanks,
> Ahmad
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
Powered by blists - more mailing lists