Re: [PATCH] multiboot on EFI

[Vladimir 'phcoder' Serbinenko]

On Wed, Aug 5, 2009 at 12:47 AM, Robert Millan<address@hidden> wrote:
> On Sun, Aug 02, 2009 at 09:53:32PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> Was successfully tested with qemu-tianocore with example multiboot
>> kernel from multiboot specification. Since real EFI has no VGA video
>> fields play a crucial feature and need to be supported. Patch is
>> coming but it will surely rely on gfxsplit patch. I also have plans to
>> extend it to x86-64 too
>
> Very nice.
Thanks. efiboot64 is available in my git but it requires allocator
framework. (efi64-bit support in all bootloader is an authomatic
advantage of using allocator framework)
>
>>  static grub_err_t
>>  grub_multiboot_boot (void)
>>  {
>> +#ifdef GRUB_MACHINE_EFI
>> +  if (! grub_efi_finish_boot_services ())
>> +     grub_fatal ("cannot exit boot services");
>> +#endif
>
> grub_fatal() terminates GRUB.  I suggest you just error out instead, so that
> user can try other things.
>
It's how it's done in efi/linux.c and according to EFI spec it can't
fail in this code. But I agree with you that both instances should be
changed
>> -      mmap_entry->type = type;
>> +      switch (type)
>> +        {
>> +        case GRUB_MACHINE_MEMORY_AVAILABLE:
>> +       mmap_entry->type = GRUB_MULTIBOOT_MEMORY_AVAILABLE;
>> +       break;
>> +
>> +     default:
>> +       mmap_entry->type = GRUB_MULTIBOOT_MEMORY_RESERVED;
>> +       break;
>
> Is this going to be extended with more `case' stanzas later?  If not,
> it'd be more readable with an if/else, or ?:.
>
It will extend when we document ACPI memory types in multiboot specification.
>> -  grub_loader_set (grub_multiboot_boot, grub_multiboot_unload, 1);
>> +  grub_loader_set (grub_multiboot_boot, grub_multiboot_unload, 0);
>
> This breaks text-mode payloads when they're loaded from gfxterm.
>
Ok I will make it use the modesetting as linux.c does. text-mode only
payloads are broken on EFI anyway since AFAIK no real EFI machine has
VGA console available unless we find a way to load one without loading
BIOS emulation. Bean may know more.
> --
> Robert Millan
>
>  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>  how) you may access your data; but nobody's threatening your freedom: we
>  still allow you to remove your data and not access it at all."
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git