[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH 1/2] powerpc-ieee1275: load grub at 8MB, not 2MB

From: Daniel Axtens
Subject: [PATCH 1/2] powerpc-ieee1275: load grub at 8MB, not 2MB
Date: Tue, 16 Nov 2021 14:42:04 +1100

RHEL9.0 builds were failing to boot with bizzare errors about module

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

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      
 | 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


>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 <>
 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_MIPS_LOONGSON_LINK_ADDR         0x80200000

reply via email to

[Prev in Thread] Current Thread [Next in Thread]