RHEL9.0 builds were failing to boot with bizzare errors about module licensing.
This was first reported under PFW but reproduces under SLOF. What is going wrong? -------------------- Much debugging later, it turned out that this was because their image was greater than 2MB - 16KB in size: - The core.elf was 2126152 = 0x207148 bytes in size with the following program headers (per readelf): Entry point 0x200000 There are 4 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000160 0x00200000 0x00200000 0x21f98 0x2971c RWE 0x8 GNU_STACK 0x0220f8 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 LOAD 0x0220f8 0x00232000 0x00232000 0x1e4e50 0x1e4e50 RWE 0x4 NOTE 0x206f48 0x00000000 0x00000000 0x00200 0x00000 R 0x4 - SLOF places the ELF file at 0x4000 (after the reserved space for interrupt handlers etc.) upwards. The image was 2126152 = 0x207148 bytes in size, so it runs from 0x4000 - 0x20b148. We'll call 0x4000 the load address. 0x0 0x4000 0x20b148 |----------|--------------| | reserved | ELF contents | - SLOF then copies the first LOAD program header (for .text). That runs for 0x21f98 bytes. It runs from (load addr + 0x160) to (load addr + 0x160 + 0x21f98) = 0x4160 to 0x260f8 and we copy it to 0x200000 to 0x221f98. This overwrites the end of the image: 0x0 0x4000 0x200000 0x221f98 |----------|------------|---------------| | reserved | ELF cont.. | .text section | - SLOF zeros the bss up to PhysAddr + MemSize = 0x22971c 0x0 0x4000 0x200000 0x221f98 0x22971c |----------|------------|---------------|--------| | reserved | ELF cont.. | .text section | bss 0s | - SLOF then goes to fulfil the next LOAD header (for mods), which is for 0x1e4e50 bytes. We copy from (load addr + 0x220f8) to (load addr + 0x220f8 + 0x1e4e50) = 0x260f8 to 0x20af48 and we copy it to 0x232000 to 0x416e50: 0x0 0x4000 0x200000 0x221f98 0x22971c |----------|------------|---------------|--------| | reserved | ELF cont.. | .text section | bss 0s | |-------------| | copied area | 0x260f8 0x20af48 This goes poorly: 0x0 0x4000 0x200000 0x221f98 0x22971c 0x232000 0x40bf08 0x416e50 |----------|------------|---------------|--------|-----|-----------|-------------| | reserved | ELF cont.. | .text section | bss 0s | pad | some mods | .text start | This matches the observations on the running system - 0x40bf08 was where the contents of memory no longer matched the contents of the ELF file. This was reported as a license verification failure on SLOF as the last module's .module_license section fell past where the corruption began. load-base --------- From LoPAR: B.10.1 Load Address The client’s load address is specified by the value of the load-base Configuration Variable. The value of load-base defines the default load address for client programs when using the load method. Load-base shall be a real address in real mode or a virtual address in virtual mode. Note that this address represents the area, within the first LMB, into which the client program file will be read by load; it does not correspond to the addresses at which the program will be executed. All of physical memory from load-base to either the start of OF physical memory or the end of physical memory, whichever comes first, shall be available for loading the client program. Note: The load-base address represents the area into which the client program will be read by load and does not correspond to the address at which the program will be executed. We can specify load-base via setting a configuration variable, via CAS, or via an 1275 PowerPC Note. We can indeed override load-base and successfully load such a binary in SLOF. Drop to the OF shell and run: 0 > a000000 to load-base-override 0 > boot Sadly, asking people to drop to OF is not a super practical solution. SLOF ignores the 1275 PowerPC Note, which is the only thing we can (sanely) set in grub rather than in OF. PFW's load-base also defaults to 0x4000 but will honour the note. (The PFW team has been asking me to get grub to include the note and set appropriate values. See the next patch.) Fixing this ----------- Unless I'm mistaken, if we want backwards compat with SLOF, we will need to change grub so that we ask the linker instruct the loader to load the program data somewhere else, giving us more headroom for the ELF image. This is fairly straight-forward to do. I've picked 8MB as that's a fairly common size for the PReP partition. We could potentially pick 4MB, I think I've seen some partitions that size too. The tests with powerpc32 using the OpenBIOS OF implementation seem to still work. I have no 32-bit Apple hardware to test on. Signed-off-by: Daniel Axtens <d...@axtens.net> --- grub-core/Makefile.core.def | 2 +- include/grub/offsets.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def index 8022e1c0a794..ce338def0f84 100644 --- a/grub-core/Makefile.core.def +++ b/grub-core/Makefile.core.def @@ -89,7 +89,7 @@ kernel = { i386_xen_pvh_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x100000'; mips_loongson_ldflags = '-Wl,-Ttext,0x80200000'; - powerpc_ieee1275_ldflags = '-Wl,-Ttext,0x200000'; + powerpc_ieee1275_ldflags = '-Wl,-Ttext,0x800000'; sparc64_ieee1275_ldflags = '-Wl,-Ttext,0x4400'; mips_arc_ldflags = '-Wl,-Ttext,$(TARGET_LINK_ADDR)'; mips_qemu_mips_ldflags = '-Wl,-Ttext,0x80200000'; diff --git a/include/grub/offsets.h b/include/grub/offsets.h index 871e1cd4c38c..8b2d6ab971be 100644 --- a/include/grub/offsets.h +++ b/include/grub/offsets.h @@ -63,7 +63,7 @@ #define GRUB_KERNEL_SPARC64_IEEE1275_LINK_ADDR 0x4400 #define GRUB_KERNEL_POWERPC_IEEE1275_LINK_ALIGN 4 -#define GRUB_KERNEL_POWERPC_IEEE1275_LINK_ADDR 0x200000 +#define GRUB_KERNEL_POWERPC_IEEE1275_LINK_ADDR 0x800000 #define GRUB_KERNEL_MIPS_LOONGSON_LINK_ADDR 0x80200000 -- 2.32.0 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel