grub-mkimage

I'm going to be on vacation next week, so I wanted to get this out so others could continue progress on PPC module loading... this is not ready for inclusion, but it is functional. Comments are welcome.

Open Firmware loads GRUB as an ELF file (rather than a binary image like x86 BIOS). So we can't just concatenate modules to the end of the grubof ELF file; we need to put them in an ELF LOAD segment. That's what this grub-mkimage does.

Right now there's still a manual step or two involved. You must build a binary "note" segment (in the proper endianness). I *thought* we could get the toolchain to build this for us with the right combination of gcc/ld/objcopy options, but now I'm not so sure. Anyways, for now from a PPC host:
gcc -c note.S
objcopy -O binary note.o note

Use the -n/--note switch to add the CHRP NOTE segment on CHRP platforms (e.g. briQ and Pegasos). NEVER use this switch on Power Macintosh. I guess that should be documented better in the help text, but anyways...

The endian-swapping code in grub-mkimage has not been tested, but may work.

Right now grub-mkimage arbitrarily loads the modules starting at 3MB, and grubof must look for them there at runtime. It's a bit awkward to tell the grubof runtime about where the modules are loaded, since we would need to parse the ELF file and edit it on disk (not as easy as just hacking a binary file at reserved offsets). That same difficulty makes it impossible right now to tell grubof runtime about the total size of the modules loaded. One possible solution there is to end the module area with a (0, 0) grub_module_header.

It may be possible to place module variables into their own section containing nothing else, yet still in a LOAD segment. Then grub-mkimage could parse the *section* table (right now it only does segments) and overwrite the contents of this section to inform the runtime of the module location. I'm not convinced it's worth the effort.

I'm firmly convinced that grub_load_modules(), currently in kern/main.c, will need to be changed to a more generic interface. For example, each arch could provide its own grub_module_start() and grub_module_end() functions. It is no longer a valid assumption that the modules begin immediately after grub_end_addr in memory. But for now I will leave that to someone (Marco?) doing the real module loading; grub-mkimage just needs to get it into memory (which I've verified it does).

-Hollis

P.S. -o is a mandatory switch for this grub-mkimage. ELF rewriting involves a lot of seeking, which you can't do with stdout...

Index: boot/powerpc/ieee1275/crt0.S
===================================================================
RCS file: /cvsroot/grub/grub2/boot/powerpc/ieee1275/crt0.S,v retrieving revision 1.3

diff -u -p -r1.3 crt0.S
@@ -18,21 +18,6 @@
  *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
-	.section ".note"
-	.align	2
-.note_section_header:
-	.long	8
-	.long	24
-	.long	0x1275
-	.string	"PowerPC"
-.note_descriptor:
-	.long   0x0             /* real-mode */
-	.long   0xffffffff      /* real-base */
-	.long   0xffffffff      /* real-size */
-	.long   0xffffffff      /* virt-base */
-	.long   0xffffffff      /* virt-size */
-	.long   0x00030000      /* load-base */
-
 .extern __bss_start
 .extern _end
 

Index: conf/powerpc-ieee1275.rmk
===================================================================
RCS file: /cvsroot/grub/grub2/conf/powerpc-ieee1275.rmk,v retrieving revision 1.14

diff -u -p -r1.14 powerpc-ieee1275.rmk
@@ -17,9 +17,13 @@ kernel_syms.lst: $(addprefix include/gru
 
 # Utilities.
 sbin_UTILITIES = grubof
-bin_UTILITIES = grub-emu
+bin_UTILITIES = grub-emu grub-mkimage
 noinst_UTILITIES = genmoddep
 
+# For grub-mkimage.
+grub_mkimage_SOURCES = util/powerpc/ieee1275/grub-mkimage.c util/misc.c \
+        util/resolve.c 
+
 # For grub-emu
 grub_emu_SOURCES = kern/main.c kern/device.c				\
 	kern/disk.c kern/dl.c kern/file.c kern/fs.c kern/err.c		\

Index: include/grub/util/misc.h
===================================================================
RCS file: /cvsroot/grub/grub2/include/grub/util/misc.h,v retrieving revision 1.5

diff -u -p -r1.5 misc.h
@@ -34,9 +34,13 @@ void *xrealloc (void *ptr, size_t size);
 char *xstrdup (const char *str);
 
 char *grub_util_get_path (const char *dir, const char *file);
+size_t grub_util_get_fp_size (FILE *fp);
 size_t grub_util_get_image_size (const char *path);
+void grub_util_read_at (void *img, size_t len, off_t offset, FILE *fp);
 char *grub_util_read_image (const char *path);
 void grub_util_load_image (const char *path, char *buf);
 void grub_util_write_image (const char *img, size_t size, FILE *out);
+void grub_util_write_image_at (const void *img, size_t size, off_t offset,
+			       FILE *out);
 
 #endif /* ! GRUB_UTIL_MISC_HEADER */

Index: util/misc.c
===================================================================
RCS file: /cvsroot/grub/grub2/util/misc.c,v
retrieving revision 1.8

diff -u -p -r1.8 misc.c
@@ -25,6 +25,7 @@
 #include <sys/stat.h>
 #include <sys/times.h>
 #include <malloc.h>
+#include <unistd.h>
 
 #include <grub/util/misc.h>
 #include <grub/mm.h>

@@ -107,6 +108,20 @@ grub_util_get_path (const char *dir, con
 }
 
 size_t
+grub_util_get_fp_size (FILE *fp)
+{
+  struct stat st;
+  
+  if (fflush (fp) == EOF)
+    grub_util_error ("fflush failed");
+
+  if (fstat (fileno (fp), &st) == -1)
+    grub_util_error ("fstat failed");
+  
+  return st.st_size;
+}
+
+size_t
 grub_util_get_image_size (const char *path)
 {
   struct stat st;

@@ -119,6 +134,16 @@ grub_util_get_image_size (const char *pa
   return st.st_size;
 }
 
+void
+grub_util_read_at (void *img, size_t size, off_t offset, FILE *fp)
+{
+  if (fseek (fp, offset, SEEK_SET) == -1)
+    grub_util_error ("fseek failed");
+
+  if (fread (img, 1, size, fp) != size)
+    grub_util_error ("read failed");
+}
+
 char *
 grub_util_read_image (const char *path)
 {

@@ -134,9 +159,8 @@ grub_util_read_image (const char *path)
   fp = fopen (path, "rb");
   if (! fp)
     grub_util_error ("cannot open %s", path);
-  
-  if (fread (img, 1, size, fp) != size)
-    grub_util_error ("cannot read %s", path);
+
+  grub_util_read_at (img, size, 0, fp);
 
   fclose (fp);
   

@@ -164,6 +188,15 @@ grub_util_load_image (const char *path, 
 }
 
 void
+grub_util_write_image_at (const void *img, size_t size, off_t offset, FILE *out)
+{
+  grub_util_info ("writing 0x%x bytes at offset 0x%x", size, offset);
+  if (fseek (out, offset, SEEK_SET) == -1)
+    grub_util_error ("write failed");
+  grub_util_write_image (img, size, out);
+}
+
+void
 grub_util_write_image (const char *img, size_t size, FILE *out)
 {
   grub_util_info ("writing 0x%x bytes", size);

@@ -0,0 +1,17 @@
+/* PT_NOTE segment for IEEE1275 CHRP binding.
+   !!! NOT for use on Power Macs!!!
+ */
+
+.note_section_header:
+	.long	8
+	.long	.note_end - .note_section_header
+	.long	0x1275
+	.string	"PowerPC"
+.note_descriptor:
+	.long   0xffffffff      /* real-mode */
+	.long   0x00c00000      /* real-base */
+	.long   0xffffffff      /* real-size */
+	.long   0xffffffff      /* virt-base */
+	.long   0xffffffff      /* virt-size */
+	.long   0x00004000      /* load-base */
+.note_end:

Nice! Enjoy your vacation.

Oh, weird. For me grubof worked on the PegasosII without doing this.

Whatever is the most flexible seems the best to me...

Right, I agree.

AS Hollis said, I'm working on the relocator for PPC at the moment. It is quite easy, but PPC_REL24 is a bit more complex. It is used for relative jumps. That means the module should be loaded close to grubof, which IMHO really sucks...

For some reason my REL24 code does not work, when it does I will send in a patch. But there are 3 options we should consider:

- Making sure REL24 should not be used. This can be done using the -mlongcall option. Still, after using this the module will not work when it uses libraries, this is a gcc bug that has been fixed last week. The library that we use is libgcc. If we choose for eliminating all calls to libgcc and if we use -mlongcall the relocator will work. The disadvantage of this solution is that the modules will get a bit bigger.

- It is possible to fix the relocator just to use PPC_REL24, but in that case the module should be loaded near grubof.

- What linux uses is jumping to some code near the module and that code does a long jump into grubof. This is the hardest solution and I don't yet have enough knowledge to do this.

I am now trying to get option 2 to work first (by using black magic to get everything loaded at the right address ;)) and when module loading works for me I will try to make 3 work. Does someone else think I try to do something else, or can someone help a bit somehow? As you might have noticed I really suck at this stuff and doing it just because no one else does. ;)

Thanks,
Marco

If I'm not mistaken, you're using the regular SVR4 ABI for PPC. It might be a good idea to take a look at the EABI (Embedded ABI) [1]

I'm not sure if you have to re-configure GCC to make it EABI-compat, or if there's a configuration switch for this. Anyway, as I said, it might be worth looking into.

Cheers,
Johan.

[1] ftp://sources.redhat.com/pub/binutils/ppc-docs/ppc-eabi-1995-01.pdf

[...]

You are right about that. Thanks a lot for the suggestion.

What I did is using the following options:

-memb -meabi -msdata=eabi

After that the R_PPC_REL24 relocation was still there. In addition to that the R_PPC_EMB_SDA21 relocation was added. So the relative relocation is still there and things got even more complex... Did I do something wrong here?

Thanks,
Marco

No idea. I thought that it would eliminate the REL24 relocations, but I was clearly wrong. See if you can get GCC to generate code that uses a GOT/TOC.

~j

Isn't that impossible because GRUB has its own GOT? I mean: GRUB has to lookup all symbols itself, etc. If I am wrong, I have no idea how to do it.

I hope to finish module loading so it at least works this weekend using the method that can still cause overflows. Can you have a look at the code when I send it in and explain it using the GRUB code?

Thanks,
Marco

As I said to you off-line, the GOT-track might not be worth even exploring. Instead, at least in my opinion, move the modules within the calling range of the "b" insn ; thus eliminating chances of overflows.

I could take a look at it, Yes.

~j

Right, but that is quite difficult.

grubof is loaded by open firmware. The module is loaded to malloc'ed memory which can be completely somewhere else. But I will think about how to get those in each other's reach.

Thanks,
Marco

Ah, my mistake then, good to know. The NOTE segment is still needed on briQ, RS/6000, and pSeries of course.

I was aiming for simplicity really... What's the simplest possible way we can inform grubof of the location of its modules? :)

24-bit offsets give you a 16 MiB range, is that really a problem?

I agree this makes sense. I'm not sure that option 3 will end up being necessary, but option 2 is obviously needed.

I've never seen relocation code before, but if it's still not working when I get back I'd be happy to take a look...

-Hollis

The solution with the other LOAD segment sounded the cleanest to me. The one that assumed it would follow immediately after the rest of GRUB sounded a bit hard to me. I mean, can you really rely on such assumptions?

The modules are loaded into the free memory of grubof. And grubof is loaded to where it is linked, IIRC. So I think that would cause problems. :)

Right, and it is finished now. I am quite sure it is required, but we can test it.

Cool.

Thanks,
Marco

I don't understand this. By "free memory of grubof" do you mean the heap? Right now, grubof is linked and loaded at 0x200000 (size is ~100KiB right now), and uses memory from 0x4000 to 0x200000 as heap space. That means the heap is well within the 16MiB 24-bit offset range.

Above grubof, we don't have much to worry about (on any system I know of) until 0x400000, which leaves about 1.5 MiB of totally unused space just above us. That space also falls well within the 24-bit offset range.

So why is there a problem finding a place to put modules that's close to grubof?

-Hollis

Ok, cool. In that case there is no problem. I thought that you changed init.c so it adds all free memory. In that case it could cause problems if you have a few hundreds of megs of memory. Perhaps we just discussed this and the change was never made.

Thanks,
Marco

A quite obvious solution would be to limit the max amount of dynamic memory to 16MB. For me, this sounds big enough...

On i386-pc, GRUB runs with 4MB memory.

Okuji

I agree.

Okuji

On PPC, it is difficult to inform runtime grub of its modules that were added post-compile. There are two pieces of module information we need at runtime: the address and the length of the modules.

x86 grub uses a binary format so grub_total_module_size can be placed at a known location at compile time, to be overwritten at install time. The address is known because the modules are appended directly after the executable.

PPC grub is an ELF executable. That makes it very difficult to overwrite a variable at install time, as the variable lives in a section at some offset inside the file. We can use a constant location for the module base address, but we still need to communicate the module size somehow. Here are some options:

1) create a very small special-purpose section (e.g. ".moduleinfo") to hold the address and size of the post-compile modules. Cons: would require more ELF header parsing in grub-mkimage; wouldn't work if we need to go XCOFF or binary on Old World Macintosh (we might need to, due to firmware limitations). 1.5) a variation of 1), embed the information inside a normal section like .text. That might be easier to work with when using non-ELF formats.
2) Store the number of modules in memory just before the first grub_module_header. This is very simple, and I have implemented a working example already:
3) Run the object through ld several times (used in Linux to get the ramdisk location). This would require running ld at install time though, and I believe we don't want to require users have a toolchain present.

#define MODULE_BASE 0x00300000 /* where grub-mkimage puts them */ void
grub_load_modules (void)
{

  struct grub_modules {
    int num_modules;
    struct grub_module_header first_header;

} *module_base = (struct grub_modules *) MODULE_BASE; struct grub_module_header *header = &module_base->first_header; int i;

for (i = 0; i < module_base->num_modules; i++)

    {
      if (! grub_dl_load_core ((char *) header + header->offset,
                               (header->size - header->offset)))
        grub_fatal ("%s", grub_errmsg);
      header = (struct grub_module_header *) ((char *) header + 
header->size);
    }
}

I am in favor of option 2. This approach could also be used for the i386 port, but I guess there are other reasons we need to overwrite fixed-location variables there, so maybe it wouldn't simplify much. (I'm looking at the VARIABLE() macros in kern/i386/pc/startup.S) So it would also be easy to move the existing grub_load_modules() into arch-specific code, and use something like the above function for the PPC port.

Comments?

-Hollis

I completely agree. Before the modules there should be a header and it can and IMHO it should be something that is portable. I can't come up with a reason why such header would make things harder instead of easier.

It would be nice if we can get rid of grub_get_end_addr'. The best thing we can do is renaming it to grub_get_dl_modules_adrr' or something like that. It should be moved to a machine specific place. After doing that you can use that new function, parse the header and initialize the modules.

Thanks,
Marco