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