Re: multiboot on EFI

[phcoder <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3144 bytes --]

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;
>>>  #define GRUB_MACHINE_MEMORY_AVAILABLE    1
>>>  #define GRUB_MACHINE_MEMORY_RESERVED    2
>>> +#define GRUB_MACHINE_MEMORY_ACPI    3
>>> +#define GRUB_MACHINE_MEMORY_NVS     4
>>>    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
>>> +#ifdef GRUB_MACHINE_PCBIOS
>>> +  grub_stop_floppy ();
>>> +#endif
>>
>> 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
> 


-- 

Regards
Vladimir 'phcoder' Serbinenko

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: efiboot.all.diff --]
[-- Type: text/x-diff; name="efiboot.all.diff", Size: 0 bytes --]