[Top][All Lists]

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

Re: multiboot on EFI

From: phcoder
Subject: Re: multiboot on EFI
Date: Sat, 04 Apr 2009 18:28:32 +0200
User-agent: Thunderbird (X11/20090318)

For those interested in testing: here is a rediff and some updates. Soon I'll split it into components
phcoder wrote:
Robert Millan wrote:
Would it be hard to split the patch and make it more granular?  I see it
implements base mmap / lsmmap support on efi, then ports the *BSD loaders
and the Multiboot loader too, and the uppermem facility.
The only reason why it's not splitted is that it's totally "preview". When it'll be more ready I'll split it
If everybody's fine with it, I'd like to suggest adding stuff to pkglib_MODULES in the same place as its corresponding variables. I've done this already a few times, and I think it makes the build system a bit more maintainable. What do
you all think about this?

I also agree with this but I temporarily kept this in architecture-specific file because of some minor problems with multiboot2. I'll fix this too

diff --git a/include/grub/i386/pc/memory.h b/include/grub/i386/pc/memory.h
index 08e92a9..e69ff77 100644
--- a/include/grub/i386/pc/memory.h
+++ b/include/grub/i386/pc/memory.h
@@ -92,6 +92,8 @@ struct grub_machine_mmap_entry
   grub_uint64_t len;
   grub_uint32_t type;
 } __attribute__((packed));

Do we need specific knowledge of these two on i386-pc ?

This one is because some loaders just copy e820 map types and I don't want to modify what OS gets on i386-pc
 /* The minimum and maximum heap size for GRUB itself.  */
 #define MIN_HEAP_SIZE    0x100000
-#define MAX_HEAP_SIZE    (16 * 0x100000)
+#define MAX_HEAP_SIZE    (1600 * 0x100000)

Is 1600 MB what we want, or to remove the limit?

I would suggest to remove the limit altogether
+  /* Bubble-sort the memory map */
+  while (done)
+    {
+      done = 0;
+      for (i = 0; i < count - 1; i++)
+    if (regions[i].start > regions[i + 1].start)
+      {
+        done = 1;
+        t = regions[i];
+        regions[i] = regions[i + 1];
+        regions[i + 1] = t;
+      }
+    }

Do we need the memory map to be sorted? AFAIK loadees can cope with unsorted
maps fine;  is there an exception?

I prefer to sort. Even as just a precaution. Actually even sorted EFI map may break a lot of OS because it usually has more entries (the runtime code isn't guaranteed to be contiguous and if it isn't it results in mmap having a lot of entries) and sometimes the first N kilobytes are defined as unusable (it's the case with qemu-tianocore) which under current definition means that low_memory=0
+  grub_stop_floppy ();

grub_stop_floppy() doesn't do any BIOS-specific stuff.  Wouldn't __i386__
be more appropiate?

I've already moved it to machine_fini just because my computer died I couldn't send the new patch


Vladimir 'phcoder' Serbinenko

reply via email to

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