[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: multiboot on EFI
Re: multiboot on EFI
Sat, 04 Apr 2009 18:28:32 +0200
Thunderbird 184.108.40.206 (X11/20090318)
For those interested in testing: here is a rediff and some updates. Soon
I'll split it into components
Robert Millan wrote:
The only reason why it's not splitted is that it's totally "preview".
When it'll be more ready I'll split it
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.
If everybody's fine with it, I'd like to suggest adding stuff to
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.
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
This one is because some loaders just copy e820 map types and I don't
want to modify what OS gets on i386-pc
diff --git a/include/grub/i386/pc/memory.h
index 08e92a9..e69ff77 100644
@@ -92,6 +92,8 @@ struct grub_machine_mmap_entry
#define GRUB_MACHINE_MEMORY_AVAILABLE 1
#define GRUB_MACHINE_MEMORY_RESERVED 2
+#define GRUB_MACHINE_MEMORY_ACPI 3
+#define GRUB_MACHINE_MEMORY_NVS 4
Do we need specific knowledge of these two 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
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
+ /* 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
maps fine; is there an exception?
I've already moved it to machine_fini just because my computer died I
couldn't send the new patch
+ grub_stop_floppy ();
grub_stop_floppy() doesn't do any BIOS-specific stuff. Wouldn't __i386__
be more appropiate?
Vladimir 'phcoder' Serbinenko