linux-kernel - Re: [PATCH v7 2/2] arm64: boot: Support Flat Image Tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <03595817-4698-46d3-b2d8-3bc40c7e723e@pengutronix.de>
Date:   Wed, 29 Nov 2023 19:35:00 +0100
From:   Ahmad Fatoum <a.fatoum@...gutronix.de>
To:     Simon Glass <sjg@...omium.org>,
        linux-arm-kernel@...ts.infradead.org
Cc:     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

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?

Please Cc me on subsequent revisions. I am interested in testing that this works for barebox
too.

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 |