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: <2746082e-4357-4608-8fd9-ffbd1ecd6ac2@pengutronix.de>
Date:   Wed, 29 Nov 2023 21:35:05 +0100
From:   Ahmad Fatoum <a.fatoum@...gutronix.de>
To:     Simon Glass <sjg@...omium.org>
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 Simon,

On 29.11.23 20:00, Simon Glass wrote:
> On Wed, 29 Nov 2023 at 11:35, Ahmad Fatoum <a.fatoum@...gutronix.de> wrote:
>> 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.

Can the script not insert load/exec addresses with dummy values to avoid confusion?

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

Thanks for the pointer. I have just sent out a first patch to add support
for kernel_noload to the barebox mailing list[1]. With that change applied,
barebox can boot the FIT images generated by this series.

Once that's accepted, I'll reply with a Tested-by.

[1]: https://lore.barebox.org/barebox/20231129203106.2417486-1-a.fatoum@pengutronix.de/T/#u

> The FIT spec[2] does not provide enough detail on exactly what
> kernel_noload means and we should improve this at some point.

Yes, that would be nice. Also straight references to e.g. U-Boot configuration
symbols could use some rewording.

Thanks,
Ahmad

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

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ