Re: Grub-devel Digest, Vol 33, Issue 19

Re: Grub-devel Digest, Vol 33, Issue 19

[Joe Bonasera]

grub-devel-request@gnu.org wrote:

>>
>> Just to be clear. For grub2 on x86, will it be true that there is only
>> a single grub2 binary that understands both elf32 and elf64?
> 
> Yes.
> 
>> Would the different tags i86-pc vs x86_64 (if any) be determined by
>> knowing if which type elf gets loaded?
> 
> My personal opinion is that we should not pass any information to the
> kernel about what format it is provided in.  

I agree about that, the OS should intrinsically know it's own format. :)

However, it shouldn't have to figure out what format the data passed
to it from the boot loader is in. If I boot a 32 bit kernel on a
64 bit capable platform/boot loader, the 32 bit kernel shouldn't have to
deal with figuring out if it's getting 32 or 64 bit information from
the boot loader.

I think it's pretty common for people to install both 32 and 64 bit
OS mixes on a single box. (I'm composing this on a machine that can
boot either 32 bit windows, 32 bit Suse, 64bit Fedora, 32 or 64 bit
Solaris partitions) all from one copy of grub and one copy of menu.lst.

> 
> If the image is an ELF64, it will be loaded as an ELF64.  So in your
> case, for x86_64 hosts, provide the kernel as an ELF64 image.  For
> IA-32, provide an ELF32 image.

Requiring that would be a big restriction from grub 0.9x, where the multiboot
info passed to the booted OS is always in a fixed 32 bit format. Making that information
(the "Multiboot Information Format" section of http://grub.enbug.org/MultibootDraft)
variant based hardware capability would greatly complicate the OS side of things.
Specifically a 32 bit OS would have to be able to decode both 32 and 64 bit
versions of the data. Yuck. If grub2 really needs to make the
format/content variant, I would much rather see it vary based on the
target OS type. Or better yet, just always use the larger size data types/content -
even for 32 bit booting.

Joe

> 
> ~j
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 190 bytes
> Desc: not available
> Url : http://lists.gnu.org/pipermail/grub-devel/attachments/20061122/c632780d/attachment.bin
> 
> ------------------------------
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
> 
> 
> End of Grub-devel Digest, Vol 33, Issue 19
> ******************************************

Re: multiboot2: variable data size

[Hollis Blanchard]

On Wed, 2006-11-22 at 12:55 -0800, Joe Bonasera wrote:
> If grub2 really needs to make the
> format/content variant, I would much rather see it vary based on the
> target OS type. Or better yet, just always use the larger size data
> types/content - even for 32 bit booting. 

I agree; I think experience has shown that not changing the data size at
all is the best solution. That will also simplify the GRUB
implementation, and I will make that change (to code and spec) soon.

-Hollis

Re: multiboot2: variable data size

[Yoshinori K. Okuji]

On Saturday 25 November 2006 03:09, Hollis Blanchard wrote:
> On Wed, 2006-11-22 at 12:55 -0800, Joe Bonasera wrote:
> > If grub2 really needs to make the
> > format/content variant, I would much rather see it vary based on the
> > target OS type. Or better yet, just always use the larger size data
> > types/content - even for 32 bit booting.
>
> I agree; I think experience has shown that not changing the data size at
> all is the best solution. That will also simplify the GRUB
> implementation, and I will make that change (to code and spec) soon.

I disagree. Please don't make such a change. I'm not willing to make 
difference between i386 and x86_64 in the Multiboot Specification.

Okuji

Re: multiboot2: variable data size

[Hollis Blanchard]

On Sat, 2006-11-25 at 04:10 +0100, Yoshinori K. Okuji wrote:
> On Saturday 25 November 2006 03:09, Hollis Blanchard wrote:
> > On Wed, 2006-11-22 at 12:55 -0800, Joe Bonasera wrote:
> > > If grub2 really needs to make the
> > > format/content variant, I would much rather see it vary based on the
> > > target OS type. Or better yet, just always use the larger size data
> > > types/content - even for 32 bit booting.
> >
> > I agree; I think experience has shown that not changing the data size at
> > all is the best solution. That will also simplify the GRUB
> > implementation, and I will make that change (to code and spec) soon.
> 
> I disagree. Please don't make such a change. I'm not willing to make 
> difference between i386 and x86_64 in the Multiboot Specification.

That's exactly the point: there will be no difference. Both
architectures will use 64-bit types.

The wording in question is this:
        "a boot loader must follow natural address size which is defined
        on each architecture"
        
        "a boot loader must define the address size as 32-bit and 64-bit
        for ELF32 and ELF64, respectively"
        
        etc.

-Hollis

Re: multiboot2: variable data size

[Yoshinori K. Okuji]

On Saturday 25 November 2006 04:33, Hollis Blanchard wrote:
> That's exactly the point: there will be no difference. Both
> architectures will use 64-bit types.

No. Both should use 32-bit, because GRUB transfers control in 32-bit mode. 
Passing 64-bit addresses would be useless in this case. Note that the memory 
map information is 64-bit even in the previous version of Multiboot Spec.

Okuji

Re: multiboot2: variable data size

[Hollis Blanchard]

On Sat, 2006-11-25 at 04:46 +0100, Yoshinori K. Okuji wrote:
> On Saturday 25 November 2006 04:33, Hollis Blanchard wrote:
> > That's exactly the point: there will be no difference. Both
> > architectures will use 64-bit types.
> 
> No. Both should use 32-bit, because GRUB transfers control in 32-bit mode. 
> Passing 64-bit addresses would be useless in this case. Note that the memory 
> map information is 64-bit even in the previous version of Multiboot Spec.

OK, I don't have a problem with this. We should clarify the spec. 
It will limit e.g. module sizes and addresses to less than 4GB, but
practically speaking I don't think that is too big a deal.

However, there are 32-bit architectures that support 36-bit addressing
(PowerPC is one of them). In some cases, physical IO is above 4GB, so
some other data structure would be required to identify those devices.
So we must remember that multiboot will not be adequate to describe an
entire system like the Open Firmware device tree does.

Do we really need x86_64-pc's "bit 17", which specifies that 64-bit
addresses are required?

-Hollis

Re: multiboot2: variable data size

[Yoshinori K. Okuji]

On Saturday 25 November 2006 05:08, Hollis Blanchard wrote:
> OK, I don't have a problem with this. We should clarify the spec.
> It will limit e.g. module sizes and addresses to less than 4GB, but
> practically speaking I don't think that is too big a deal.

I agree, although I don't know what will happen in the future. ;)

> However, there are 32-bit architectures that support 36-bit addressing
> (PowerPC is one of them). In some cases, physical IO is above 4GB, so
> some other data structure would be required to identify those devices.
> So we must remember that multiboot will not be adequate to describe an
> entire system like the Open Firmware device tree does.

I am afraid that you misunderstand the meaning of the addressing size in the 
Multiboot Spec. It only means how a boot loader should inspect memory-related 
values. For instance, the addresses in a Multiboot header. You can still pass 
arbitrary size of values in Multiboot information, regardless of 32-bit or 
64-bit.

> Do we really need x86_64-pc's "bit 17", which specifies that 64-bit
> addresses are required?

I don't know, for x86_64. The idea is to pass something "natural". My 
assumption was that, if an image is ELF64, the user wants to use 64-bit 
pointers, even if real addresses never be over 4GB. Someone who has 
experience should tell us.

Okuji

Re: multiboot2: variable data size

[Hollis Blanchard]

On Sat, 2006-11-25 at 05:36 +0100, Yoshinori K. Okuji wrote:
> On Saturday 25 November 2006 05:08, Hollis Blanchard wrote:
> > OK, I don't have a problem with this. We should clarify the spec.
> > It will limit e.g. module sizes and addresses to less than 4GB, but
> > practically speaking I don't think that is too big a deal.
> 
> I agree, although I don't know what will happen in the future. ;) 

In the future we can provide tags like "MODULE64", which will use 64-bit
values instead of 32-bit. (Maybe a bad example, but you get the idea. :)

Along that line of thinking, we should explicitly identify data widths
in each tag, rather than a generic "everything is 32-bit unless
specified otherwise".

-Hollis

Re: multiboot2: variable data size

[Johan Rydberg]

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

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> On Saturday 25 November 2006 04:33, Hollis Blanchard wrote:
>> That's exactly the point: there will be no difference. Both
>> architectures will use 64-bit types.
>
> No. Both should use 32-bit, because GRUB transfers control in 32-bit mode. 
> Passing 64-bit addresses would be useless in this case. Note that the memory 
> map information is 64-bit even in the previous version of Multiboot Spec.

That will not be true for x86_64-efi, which will have to run in long
mode.

~j

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: multiboot2: variable data size

[Yoshinori K. Okuji]

On Tuesday 28 November 2006 10:29, Johan Rydberg wrote:
> "Yoshinori K. Okuji" <okuji@enbug.org> writes:
> > On Saturday 25 November 2006 04:33, Hollis Blanchard wrote:
> >> That's exactly the point: there will be no difference. Both
> >> architectures will use 64-bit types.
> >
> > No. Both should use 32-bit, because GRUB transfers control in 32-bit
> > mode. Passing 64-bit addresses would be useless in this case. Note that
> > the memory map information is 64-bit even in the previous version of
> > Multiboot Spec.
>
> That will not be true for x86_64-efi, which will have to run in long
> mode.

Oh, sorry. I meant "x86_64-pc" in the previous message. I just omitted "pc". 
When the firmware is different, it is feasible to make a different spec, 
but...

But is it true that EFI starts with 64-bit mode? Where is it defined? In UEFI? 
Could you give me a pointer?

Okuji

Re: multiboot2: variable data size

[bibo,mao]

Yoshinori K. Okuji wrote:
> On Tuesday 28 November 2006 10:29, Johan Rydberg wrote:
>  > "Yoshinori K. Okuji" <okuji@enbug.org> writes:
>  > > On Saturday 25 November 2006 04:33, Hollis Blanchard wrote:
>  > >> That's exactly the point: there will be no difference. Both
>  > >> architectures will use 64-bit types.
>  > >
>  > > No. Both should use 32-bit, because GRUB transfers control in 32-bit
>  > > mode. Passing 64-bit addresses would be useless in this case. Note that
>  > > the memory map information is 64-bit even in the previous version of
>  > > Multiboot Spec.
>  >
>  > That will not be true for x86_64-efi, which will have to run in long
>  > mode.
> 
> Oh, sorry. I meant "x86_64-pc" in the previous message. I just omitted "pc".
> When the firmware is different, it is feasible to make a different spec,
> but...
> 
> But is it true that EFI starts with 64-bit mode? Where is it defined? In UEFI?
> Could you give me a pointer?
> 
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
bibo,mao

Re: multiboot2: variable data size

[tgingold]

Quoting "Yoshinori K. Okuji" <okuji@enbug.org>:

> On Tuesday 28 November 2006 10:29, Johan Rydberg wrote:
> > "Yoshinori K. Okuji" <okuji@enbug.org> writes:
> > > On Saturday 25 November 2006 04:33, Hollis Blanchard wrote:
> > >> That's exactly the point: there will be no difference. Both
> > >> architectures will use 64-bit types.
> > >
> > > No. Both should use 32-bit, because GRUB transfers control in 32-bit
> > > mode. Passing 64-bit addresses would be useless in this case. Note that
> > > the memory map information is 64-bit even in the previous version of
> > > Multiboot Spec.
> >
> > That will not be true for x86_64-efi, which will have to run in long
> > mode.
>
> Oh, sorry. I meant "x86_64-pc" in the previous message. I just omitted "pc".
> When the firmware is different, it is feasible to make a different spec,
> but...
>
> But is it true that EFI starts with 64-bit mode? Where is it defined? In
> UEFI?
> Could you give me a pointer?
Yes, cf tianocore.org.  When compiled for x64, it is x64 code :-)

Tristan.

Re: multiboot2: variable data size

[Yoshinori K. Okuji]

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.

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.

Okuji

Re: multiboot2: variable data size

[Johan Rydberg]

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

"bibo,mao" <bibo.mao@intel.com> writes:

> 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.

My opinion is that bzImages should be avoided on EFI platforms, or the
decompress-code in Linux has to be rewritten.  

It took me a good couple of hours of debugging to find out that Linux
simply ignores the memory layout and assumes that low memory is free
to use as it likes.

~j

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: multiboot2: variable data size

[bibo,mao]

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.
> 
> 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?

thanks
bibo,mao


> 
> Okuji
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
> 

Re: multiboot2: variable data size

[bibo,mao]

Johan Rydberg wrote:
> "bibo,mao" <bibo.mao@intel.com> writes:
> 
>  > 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.
> 
> My opinion is that bzImages should be avoided on EFI platforms, or the
> decompress-code in Linux has to be rewritten. 
bzImage supporting mainly is to be compliant with legacy bios, user need
not care for detailed bootloader procedure, user always installs linux
kernel with command "make install" which will generate bzImage format.
Now on some platform there are two kinds of bios: efi bios and legacy
bios, if bzImage is supported then one kernel image can run two kinds
of bios.
> 
> It took me a good couple of hours of debugging to find out that Linux
> simply ignores the memory layout and assumes that low memory is free
> to use as it likes.
current decompress-code with bzImage possibly touches low memory at
0x1000--0x9000, or decompress-code needs to be rewritten, or put mode
switching code below 0x1000.

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

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
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel