On Tue, Nov 21, 2023 at 08:17:30PM +0000, Caleb Connolly wrote: > > > On 21/11/2023 19:07, Tom Rini wrote: > > On Tue, Nov 21, 2023 at 05:09:25PM +0000, Caleb Connolly wrote: > > > >> Let this option be enabled dynamically for boards that support multiple > >> mechanisms for booting U-Boot (e.g. as a first-stage or chainloaded > >> bootloader). > >> > >> Signed-off-by: Caleb Connolly <caleb.conno...@linaro.org> > >> --- > >> This patch has no dependencies > >> > >> Cc: Simon Glass <s...@chromium.org> > >> --- > >> arch/arm/Kconfig | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > >> index bd48131292e3..1add4282f336 100644 > >> --- a/arch/arm/Kconfig > >> +++ b/arch/arm/Kconfig > >> @@ -81,7 +81,7 @@ config SPL_SYS_NO_VECTOR_TABLE > >> > >> config LINUX_KERNEL_IMAGE_HEADER > >> depends on ARM64 > >> - bool > >> + bool "Linux kernel binary header" > >> help > >> Place a Linux kernel image header at the start of the U-Boot binary. > >> The format of the header is described in the Linux kernel source at > > > > Why are we not select'ing this like the other platforms which need the > > same do? > > On some Qualcomm boards we can boot either as a Linux kernel or we can > replace the first-stage bootloader. To run as the primary bootloader we > unset this option and enable REMAKE_ELF as well as configuring a few > other things. > > Would it make more sense to introduce a Qualcomm specific config option > to handle these cases?
Well, part of the image header is that if you try and execute it, it's a jump over the rest of the header, yes? So can't we still do the REMAKE_ELF on top of it? -- Tom
signature.asc
Description: PGP signature