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

Attachment: signature.asc
Description: PGP signature

Reply via email to