Re: multiboot2: variable data size

[Andrei E. Warkentin]

Inlined.

On 28.11.2006, at 19:55, bibo,mao wrote:

> Yoshinori K. Okuji wrote:
> > On Tuesday 28 November 2006 13:46, bibo,mao wrote:
> >  > yes, x84_64EFI starts with 64-bit long mode and page enabled 
> > (virtual
> >  > address equals physical address) if it is x86_64 efi bios, it  
> > is defined in
> >  > section 2.3.4 of UEFI Specification Version 2.0.
> >  >
> >  > If kernel image is bzImage, x64 efi bootloader need switch to  
> > 32 bit
> >  > protect mode(or real mode) from 64 bit long mode, and if kernel  
> > image is
> >  > gzipped/plain format, efi bootloader can directly jump to 64- 
> > bit kernel
> >  > entry address without mode switch.
> > Thanks for your detailed information. So does it mean that GRUB  
> > needs to
> > provide a PE32+ application to EFI, if it is on x86_64? Or does it  
> > understand
> > PE32? More information is welcome.
> Now I tried on x86_64, it seems that x86_64 efi bios does not  
> support PE32
> format, PE32+ application should be provided.

Yes. Grub for x64 EFI should be a PE32+ image.

> > BTW, in the current implementation, GRUB skips real mode setup  
> > code in Linux
> > and directly jumps to a protected mode entry on EFI. Can we use  
> > the same
> > trick with bzImage on x86_64? Mode switching is not difficult, but  
> > if we can
> > omit it, that would be much easier to implement.
> On i386 efi platform, real mode setup code can be skipped with  
> bzImage. But on
> x86_64 efi platform with bzImage format, it seems that it need  
> switch to 32-bit
> protect mode at least.
> We can discard mode switching at beginning so that it can boot  
> kernel image with
> gzipped format. Mode switching code is not difficult and very  
> small, the problem
> is that x86_64 bootloader(pe32+) can be loaded at address beyond  
> 4G, but mode
> switching code must be within 4G, also self-uncompressed bzimage  
> code possibly
> flushes mode switching code. I do not know which address is safe to  
> put switching code, how about 0x7c00?

That is not a problem.  AllocatePages() in the UEFI runtime services  
can be told to allocate memory below a certain address by passing  
AllocateMaxAddress as the EFI_ALLOCATE_TYPE. The UEFI specification  
is your friend :) – http://www.uefi.org/


> thanks
> bibo,mao
>
>
> > Okuji
> > _______________________________________________
> > Grub-devel mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel