Re: [PATCH 5/5] x86_64 EFI support -v3: EFI document

[Etienne Lorrain <etienne_lorrain@yahoo.fr>]

Eric W Biederman wrote:
> >> This is the classic skip the 16bit code and enter the kernel
> >> in 32bit mode filling in the fields that the 16bit mode code would
> >> have filled in the same way approach.
> > ......
> >
> > For in tree code it can be just updated. But weirdo-EFI-boot loader
> > cannot.
>
> So far the logic has been.
>
> Inspect bzImage.  And get boot protocol version.
> If field we need for returning data is not supported do not give
> data.  Or something like that.  Usually the fields always exist
> and you can just fill them in and we only append to the boot
> protocol structure.
>
> In practice this has been working for the last 7 years or so,
> for EFI, and LinuxBIOS, and kexec, and Gujin and I don't remember what
> else.

 Note that Gujin has a simple problem by using that 32 bits entry point:
there is no way to detect if the bzImage is compiled for 32 bits or 64 bits,
and Linux-real-mode calls a BIOS service for 64 bits only (to tell the BIOS you
are going to 64 bits - interrupt not really documented).
 Gujin can now be set to start at the 16 bits entry point, and load ELF32/ELF64
where you now the target word size, but the 32 bits entry point will "forget"
to call that service if the Linux kernel is 64 bits.
 The 32 bits entry point can still be used (-p parameter of tiny.exe) because
there seems to be a problem using the 16 bits entry point under DOS, at least
the old assembly version of the code - no more details known.

 Etienne.


      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail