VBE info request bit per Multiboot Specification 1

VBE info request bit per Multiboot Specification 1

[Francis Shim]

Hi,

In the Multiboot specifications (version 1), there is a flag that the OS
Image can set to request that the boot loader provide VBE information to
the OS kernel upon boot up via the Multiboot Information structure.
Legacy GRUB (GRUB1) deos not support this feature without a patch that
is circulating around in OS development websites; however, I was
wondering if GRUB2 has the feature fully supported in its most
up-to-date SVN version.  I tried using GRUB2 version 1.96 using Fedora's
rpm; however, when I use "multiboot" as the kernel type, GRUB2 complains
that the feature is not supported.

What is the current direction that GRUB2 is taking with regards to VBE
support and how will it tie in with your graphical boot initiative?
Will Multiboot Specification version 2 be supported and will it have
enhanced VBE or video information support?

Thanks in advance for any responses.

Peace,
Frank

Re: VBE info request bit per Multiboot Specification 1

[Robert Millan]

On Tue, Aug 04, 2009 at 01:37:19PM -0400, Francis Shim wrote:
> Hi,
> 
> In the Multiboot specifications (version 1), there is a flag that the OS
> Image can set to request that the boot loader provide VBE information to
> the OS kernel upon boot up via the Multiboot Information structure.
> Legacy GRUB (GRUB1) deos not support this feature without a patch that
> is circulating around in OS development websites;

Hi,

It's not implemented.  But since you mention that a patched GRUB Legacy
supports it, I assume there are a number of OSes that implement it.

Can you provide us with a test case?  This would make an implementation
of the GRUB side much easier.

Btw, would you like to work on this?  It's not difficult, as we already
support something analogous in the Linux loader.

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

Re: VBE info request bit per Multiboot Specification 1

[Jan Setje-Eilers]

  <re-send after fixing subscription>

> On Tue, Aug 04, 2009 at 01:37:19PM -0400, Francis Shim wrote:
>> Hi,
>> 
>> In the Multiboot specifications (version 1), there is a flag that
>> the OS Image can set to request that the boot loader provide VBE
>> information to the OS kernel upon boot up via the Multiboot
>> Information structure. Legacy GRUB (GRUB1) deos not support this
>> feature without a patch that is circulating around in OS
>> development websites;
> 
> Hi,
> 
> It's not implemented.  But since you mention that a patched GRUB 
> Legacy supports it, I assume there are a number of OSes that
> implement it.

  FWIW, we've got a prototype VESA console for Solaris that uses that
structure to avoid additional mode switches. In fact, was just looking
into what this looked like in GRUB 2 when someone pointed this thread
out to me.

  If the structure is built up compatibly, things should just work.

> Can you provide us with a test case?  This would make an
> implementation of the GRUB side much easier.
> 
> Btw, would you like to work on this?  It's not difficult, as we
> already support something analogous in the Linux loader.

  Unless there's another preferred interface (or someone beats us to it).
we'll likely end up filling in. Considering the VBE code that's already
there this is fairly trivial.

-jan

Re: VBE info request bit per Multiboot Specification 1

[Francis Shim]

On Tue, 2009-08-04 at 22:35 +0200, Robert Millan wrote:
> On Tue, Aug 04, 2009 at 01:37:19PM -0400, Francis Shim wrote:
> > In the Multiboot specifications (version 1), there is a flag that the OS
> > Image can set to request that the boot loader provide VBE information to
> > the OS kernel upon boot up via the Multiboot Information structure.
> > Legacy GRUB (GRUB1) deos not support this feature without a patch that
> > is circulating around in OS development websites;
> It's not implemented.  But since you mention that a patched GRUB Legacy
> supports it, I assume there are a number of OSes that implement it.

I have not checked extensively as to which multiboot OS uses the VBE
information; however, I have noticed that there is a strong push for OS
developers, including Linux, to be able to have video mode information
ready earlier.  In addition, OSes are taking on the task of actually
setting a video mode along with any memory mapping that comes with it
(With Linux... think kernel mode-setting).

In my case, I am only involved with my own personal hobby OS which I
decided to make multiboot (version 1) compliant.  With Legacy GRUB it
was able to boot using the multiboot-ELF loader; but with GRUB2 I
noticed that it was more explicit and I decided to try the true
"multiboot" kernel type to experiment.  It was then that I noticed that
the VBE info request flag was not implemented.  If I keep the flag clear
and not use VBE information then the OS is booted as expected.  What
seems a bit inconsistent is that Legacy GRUB boots whether the flag is
clear or not, and will simply indicate that there is no VBE information
in the Multiboot Information structure, but GRUB2 will not boot if the
VBE information request flag is set; hence, the OS becomes "unbootable"
versus just not being able to get VBE information.

There is a good reason why GRUB (or any muliboot bootloader) should be
able to provide VBE information: BIOS int calls (for VBE) require real
mode, but GRUB (or any multiboot bootloader) loads the OS into a 32-bit
protected mode environment and loads only above the 1 MB watermark (x86
case).  If the OS have to switch back to real mode, it becomes just
downright messy and un-necessary since GRUB started up in real mode in
the first place and switched to 32-bit protected mode.  The reason I
mention the 1 MB watermark is because if the multiboot OS kernel want to
have "mode switching code" to get the missing VBE information then it
will not be able to simply have 16-bit code loaded below the 1 MB by the
bootloader, but will have to copy 16-bit relocatable code into the
desired area below 1 MB...  something that is a bit like SMC (self
modifying code), very frowned upon.

> Can you provide us with a test case?  This would make an implementation
> of the GRUB side much easier.

Do you mean for GRUB2?  I can simply make a very simple
multiboot-compliant OS that request VBE information and just checks for
the VBE information in the Multiboot Information structure.

> Btw, would you like to work on this?  It's not difficult, as we already
> support something analogous in the Linux loader.

I would love to work on it, but I am unable to do so due to other
priorities (sigh).  The test case will have to do unless someone else
would like to pitch that in.

Peace,
Frank

Re: VBE info request bit per Multiboot Specification 1

[Vladimir 'phcoder' Serbinenko]

On Wed, Aug 5, 2009 at 1:49 AM, Jan Setje-Eilers<setje@sun.com> wrote:
>  <re-send after fixing subscription>
>
>> On Tue, Aug 04, 2009 at 01:37:19PM -0400, Francis Shim wrote:
>>>
>>> Hi,
>>>
>>> In the Multiboot specifications (version 1), there is a flag that
>>> the OS Image can set to request that the boot loader provide VBE
>>> information to the OS kernel upon boot up via the Multiboot
>>> Information structure. Legacy GRUB (GRUB1) deos not support this
>>> feature without a patch that is circulating around in OS
>>> development websites;
>>
>> Hi,
>>
>> It's not implemented.  But since you mention that a patched GRUB Legacy
>> supports it, I assume there are a number of OSes that
>> implement it.
>
>  FWIW, we've got a prototype VESA console for Solaris that uses that
> structure to avoid additional mode switches. In fact, was just looking
> into what this looked like in GRUB 2 when someone pointed this thread
> out to me.
>
This is nice. This has an additional benefit of working on EFI since
grub will fill the video info it's able to retrieve through EFI or its
own drivers. This implies that some non-essential field will stay
unset but I hope that OSes won't use it. I already have a bit of
experimental code for it but what I need is a small payload which will
draw something based on this info and more free time
>  If the structure is built up compatibly, things should just work.
>
>> Can you provide us with a test case?  This would make an
>> implementation of the GRUB side much easier.
>>
>> Btw, would you like to work on this?  It's not difficult, as we
>> already support something analogous in the Linux loader.
>
>  Unless there's another preferred interface (or someone beats us to it).
> we'll likely end up filling in. Considering the VBE code that's already
> there this is fairly trivial.
>
> -jan
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

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

Re: VBE info request bit per Multiboot Specification 1

[Robert Millan]

On Tue, Aug 04, 2009 at 04:49:57PM -0700, Jan Setje-Eilers wrote:
>  <re-send after fixing subscription>
>
>> On Tue, Aug 04, 2009 at 01:37:19PM -0400, Francis Shim wrote:
>>> Hi,
>>>
>>> In the Multiboot specifications (version 1), there is a flag that
>>> the OS Image can set to request that the boot loader provide VBE
>>> information to the OS kernel upon boot up via the Multiboot
>>> Information structure. Legacy GRUB (GRUB1) deos not support this
>>> feature without a patch that is circulating around in OS
>>> development websites;
>>
>> Hi,
>>
>> It's not implemented.  But since you mention that a patched GRUB  
>> Legacy supports it, I assume there are a number of OSes that
>> implement it.
>
>  FWIW, we've got a prototype VESA console for Solaris that uses that
> structure to avoid additional mode switches. In fact, was just looking
> into what this looked like in GRUB 2 when someone pointed this thread
> out to me.
>
>  If the structure is built up compatibly, things should just work.

That's very nice.  I assume it follows the Multiboot spec?  (in theory,
that should suffice, but that's just theory ;-)).

>> Can you provide us with a test case?  This would make an
>> implementation of the GRUB side much easier.
>>
>> Btw, would you like to work on this?  It's not difficult, as we
>> already support something analogous in the Linux loader.
>
>  Unless there's another preferred interface (or someone beats us to it).
> we'll likely end up filling in. Considering the VBE code that's already
> there this is fairly trivial.

Very well!

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