Daniel Axtens <d...@axtens.net> writes: > 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>
Shipping this one already. Reviewed-by: Robbie Harwood <rharw...@redhat.com> Be well, --Robbie
signature.asc
Description: PGP signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel