ARMv8: add optional Linux kernel image header
Subsystems (3)
PATCH 1/2 ARMv8: add optional Linux kernel image header
From: Stephen Warren <[email protected]>
Allow placing a Linux kernel image header at the start of the U-Boot binary. This is useful since the image header reports the amount of memory (BSS and similar) that U-Boot needs to use, but that isn't part of the binary size. This can be used by the code that loads U-Boot into memory to determine where to load U-Boot, based on other users of memory.
---
This series relies (at the very least for diff context) on the previous series I sent Dec 19: ARM: tegra: don't use CONFIG_SPL_TEXT_BASE when no SPL ... ARM: tegra: use CONFIG_SYS_INIT_SP_BSS_OFFSET.
arch/arm/Kconfig | 16 ++++ .../arm/cpu/armv8/linux-kernel-image-header-vars.h | 86 ++++++++++++++++++++++ arch/arm/cpu/armv8/start.S | 4 +- arch/arm/cpu/armv8/u-boot.lds | 4 + arch/arm/include/asm/boot0-linux-kernel-header.h | 49 ++++++++++++ 5 files changed, 158 insertions(+), 1 deletion(-) create mode 100644 arch/arm/cpu/armv8/linux-kernel-image-header-vars.h create mode 100644 arch/arm/include/asm/boot0-linux-kernel-header.h
arch/arm/Kconfig +16 -0
@@ -32,6 +32,22 @@ config SYS_INIT_SP_BSS_OFFSET calculate the stack pointer. This offset should be large enough so that the early malloc region, global data (gd), and early stack usage do not overlap any appended DTB. + +config LINUX_KERNEL_IMAGE_HEADER + bool + help + Place a Linux kernel image header at the start of the U-Boot binary. + This is useful since the image header reports the amount of memory + (BSS and similar) that U-Boot needs to use, but that isn't part of + the binary size. + +if LINUX_KERNEL_IMAGE_HEADER +config LNX_KRNL_IMG_TEXT_OFFSET_BASE + hex + help + The value subtracted from CONFIG_SYS_TEXT_BASE to calculate the + TEXT_OFFSET value written in to the Linux kernel image header. +endif endif config STATIC_RELA
arch/arm/cpu/armv8/linux-kernel-image-header-vars.h new file +86 -0
86 lines not on this page · raw message
arch/arm/cpu/armv8/start.S +3 -1
@@ -19,7 +19,9 @@ .globl _start _start: -#ifdef CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK +#if defined(LINUX_KERNEL_IMAGE_HEADER) +#include <asm/boot0-linux-kernel-header.h> +#elif defined(CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK) /* * Various SoCs need something special and SoC-specific up front in * order to boot, allow them to set that in their boot0.h file and then
arch/arm/cpu/armv8/u-boot.lds +4 -0
@@ -159,4 +159,8 @@ SECTIONS /DISCARD/ : { *(.plt*) } /DISCARD/ : { *(.interp*) } /DISCARD/ : { *(.gnu*) } + +#ifdef CONFIG_LINUX_KERNEL_IMAGE_HEADER +#include "linux-kernel-image-header-vars.h" +#endif }
arch/arm/include/asm/boot0-linux-kernel-header.h new file +49 -0
49 lines not on this page · raw message
Signature · 1 line
2.15.1
PATCH 2/2 ARM: tegra: use LINUX_KERNEL_IMAGE_HEADER
From: Stephen Warren <[email protected]>
Enable CONFIG_LINUX_KERNEL_IMAGE_HEADER for all 64-bit Tegra boards. cboot (the boot SW that runs before U-Boot) will eventually use this information.
--- arch/arm/mach-tegra/Kconfig | 6 ++++++ 1 file changed, 6 insertions(+)
arch/arm/mach-tegra/Kconfig +6 -0
@@ -60,8 +60,14 @@ config TEGRA_ARMV7_COMMON config TEGRA_ARMV8_COMMON bool "Tegra 64-bit common options" select ARM64 + select LINUX_KERNEL_IMAGE_HEADER select TEGRA_COMMON +if TEGRA_ARMV8_COMMON +config LNX_KRNL_IMG_TEXT_OFFSET_BASE + default 0x80000000 +endif + choice prompt "Tegra SoC select" optional
Signature · 1 line
2.15.1
PATCH 2/2 ARM: tegra: use LINUX_KERNEL_IMAGE_HEADER
Hi Stephen,
Quoted 5 lines · Stephen Warren
From: Stephen Warren <[email protected]>
Enable
CONFIG_LINUX_KERNEL_IMAGE_HEADERfor all 64-bit Tegra boards. cboot (the boot SW that runs before U-Boot) will eventually use this information.
How does U-Boot use it? Does it not come from the FIT?
Quoted 26 lines
Signed-off-by Stephen Warren <[email protected]>--- arch/arm/mach-tegra/Kconfig | 6 ++++++ 1 file changed, 6 insertions(+)arch/arm/mach-tegra/Kconfig +6
-1@@ -60,8 +60,14 @@ config TEGRA_ARMV7_COMMON config TEGRA_ARMV8_COMMON bool "Tegra 64-bit common options" select ARM64 + select LINUX_KERNEL_IMAGE_HEADER select TEGRA_COMMON +if TEGRA_ARMV8_COMMON +config LNX_KRNL_IMG_TEXT_OFFSET_BASE + default 0x80000000 +endif + choice prompt "Tegra SoC select" optional --
Quoted 2 lines
2.15.1
Regards,
Simon
PATCH 2/2 ARM: tegra: use LINUX_KERNEL_IMAGE_HEADER
Quoted 10 lines · Simon Glass
Hi Stephen,
Quoted 5 lines · Stephen Warren
From: Stephen Warren <[email protected]>
Enable
CONFIG_LINUX_KERNEL_IMAGE_HEADERfor all 64-bit Tegra boards. cboot (the boot SW that runs before U-Boot) will eventually use this information.How does U-Boot use it? Does it not come from the FIT?
U-Boot doesn't use the header itself. Rather, the header provides information (e.g. BSS usage) to whatever SW is loading U-Boot into RAM. We don't use FIT at all; I'd rather our boot flow not know about bootloader-specific data formats.
PATCH 1/2 ARMv8: add optional Linux kernel image header
In reply to Stephen WarrenQuoted 8 lines · Stephen Warren
From: Stephen Warren <[email protected]>
Allow placing a Linux kernel image header at the start of the U-Boot binary. This is useful since the image header reports the amount of memory (BSS and similar) that U-Boot needs to use, but that isn't part of the binary size. This can be used by the code that loads U-Boot into memory to determine where to load U-Boot, based on other users of memory.
Quoted 5 lines
Signed-off-by Stephen Warren <[email protected]>---
This series relies (at the very least for diff context) on the previous series I sent Dec 19: ARM: tegra: don't useCONFIG_SPL_TEXT_BASEwhen no SPL ... ARM: tegra: useCONFIG_SYS_INIT_SP_BSS_OFFSET.
Neat. Are the Linux folks encouraging other projects to re-use this header? Is there somewhere we can point to as reference for the format for the Kconfig help as well, not just the text? Thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180103/fd04853e/attachment.sig>
PATCH 1/2 ARMv8: add optional Linux kernel image header
Quoted 10 lines · Tom Rini
Quoted 8 lines · Stephen Warren
From: Stephen Warren <[email protected]>
Allow placing a Linux kernel image header at the start of the U-Boot binary. This is useful since the image header reports the amount of memory (BSS and similar) that U-Boot needs to use, but that isn't part of the binary size. This can be used by the code that loads U-Boot into memory to determine where to load U-Boot, based on other users of memory.
Quoted 8 lines
Quoted 5 lines
Signed-off-by Stephen Warren <[email protected]>---
This series relies (at the very least for diff context) on the previous series I sent Dec 19: ARM: tegra: don't useCONFIG_SPL_TEXT_BASEwhen no SPL ... ARM: tegra: useCONFIG_SYS_INIT_SP_BSS_OFFSET.Neat. Are the Linux folks encouraging other projects to re-use this header?
Not that I'm aware of, but mainly because I haven't talked to upstream kernel people about this at all. I implemented this because in recent versions of Linux4Tegra, for all 64-bit SoCs, our main CPU EL2/EL1 boot path is either:
cboot -> Linux kernel
cboot -> U-Boot -> Linux kernel
cboot is an NVIDIA binary bootloader. cboot wants to know about BSS/... usage of the binary it loads, which can be determined from the Linux kernel image header, but we don't want cboot to take different paths when booting Linux or U-Boot (or indeed anything at all), so the simplest thing was to make U-Boot look as identical to a Linux kernel as possible.
Quoted 2 lines
Is there somewhere we can point to as reference for the format for the
Kconfighelp as well, not just the text? Thanks!
The Linux kernel file Documentation/arm64/booting.txt does describe the format. Should I respin and add that filename to the Kconfig text?
PATCH 1/2 ARMv8: add optional Linux kernel image header
Quoted 34 lines · Stephen Warren
Quoted 10 lines · Tom Rini
Quoted 8 lines · Stephen Warren
From: Stephen Warren <[email protected]>
Allow placing a Linux kernel image header at the start of the U-Boot binary. This is useful since the image header reports the amount of memory (BSS and similar) that U-Boot needs to use, but that isn't part of the binary size. This can be used by the code that loads U-Boot into memory to determine where to load U-Boot, based on other users of memory.
Quoted 8 lines
Quoted 5 lines
Signed-off-by Stephen Warren <[email protected]>---
This series relies (at the very least for diff context) on the previous series I sent Dec 19: ARM: tegra: don't useCONFIG_SPL_TEXT_BASEwhen no SPL ... ARM: tegra: useCONFIG_SYS_INIT_SP_BSS_OFFSET.Neat. Are the Linux folks encouraging other projects to re-use this header?
Not that I'm aware of, but mainly because I haven't talked to upstream kernel people about this at all. I implemented this because in recent versions of Linux4Tegra, for all 64-bit SoCs, our main CPU EL2/EL1 boot path is either:
cboot -> Linux kernel
cboot -> U-Boot -> Linux kernelcboot is an NVIDIA binary bootloader. cboot wants to know about BSS/... usage of the binary it loads, which can be determined from the Linux kernel image header, but we don't want cboot to take different paths when booting Linux or U-Boot (or indeed anything at all), so the simplest thing was to make U-Boot look as identical to a Linux kernel as possible.
Quoted 5 lines
Quoted 2 lines
Is there somewhere we can point to as reference for the format for the
Kconfighelp as well, not just the text? Thanks!The Linux kernel file
Documentation/arm64/booting.txtdoes describe the format. Should I respin and add that filename to theKconfigtext?
Yes, and I feel like it can't hurt to let the arm64 maintainers know too as frankly it's a good idea and more projects should make use of it, so maybe it should be a bit more formally documented (in one of those fancy new rst files?) or something.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180103/68583c20/attachment.sig>
PATCH 1/2 ARMv8: add optional Linux kernel image header
Quoted 38 lines · Tom Rini
Quoted 37 lines · Stephen Warren
Quoted 10 lines · Tom Rini
Quoted 8 lines · Stephen Warren
From: Stephen Warren <[email protected]>
Allow placing a Linux kernel image header at the start of the U-Boot binary. This is useful since the image header reports the amount of memory (BSS and similar) that U-Boot needs to use, but that isn't part of the binary size. This can be used by the code that loads U-Boot into memory to determine where to load U-Boot, based on other users of memory.
Quoted 8 lines
Quoted 5 lines
Signed-off-by Stephen Warren <[email protected]>---
This series relies (at the very least for diff context) on the previous series I sent Dec 19: ARM: tegra: don't useCONFIG_SPL_TEXT_BASEwhen no SPL ... ARM: tegra: useCONFIG_SYS_INIT_SP_BSS_OFFSET.Neat. Are the Linux folks encouraging other projects to re-use this header?
Not that I'm aware of, but mainly because I haven't talked to upstream kernel people about this at all. I implemented this because in recent versions of Linux4Tegra, for all 64-bit SoCs, our main CPU EL2/EL1 boot path is either:
cboot -> Linux kernel
cboot -> U-Boot -> Linux kernelcboot is an NVIDIA binary bootloader. cboot wants to know about BSS/... usage of the binary it loads, which can be determined from the Linux kernel image header, but we don't want cboot to take different paths when booting Linux or U-Boot (or indeed anything at all), so the simplest thing was to make U-Boot look as identical to a Linux kernel as possible.
Quoted 2 lines
Is there somewhere we can point to as reference for the format for the
Kconfighelp as well, not just the text? Thanks!
Quoted 7 lines
Quoted 2 lines
The Linux kernel file
Documentation/arm64/booting.txtdoes describe the format. Should I respin and add that filename to theKconfigtext?Yes, and I feel like it can't hurt to let the arm64 maintainers know too as frankly it's a good idea and more projects should make use of it, so maybe it should be a bit more formally documented (in one of those fancy new rst files?) or something.
I talked to Catalin Marinas (one of the arch/arm64 maintainers) on IRC and he said he didn't see any issue with this approach.