Multiboot video in GRUB (Re: [RFC] Multiboot ammendment: non-VBE video)
On Sat, Jan 02, 2010 at 07:26:08PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > === added file 'ChangeLog.efiboot' > --- ChangeLog.efiboot 1970-01-01 00:00:00 + > +++ ChangeLog.efiboot 2010-01-02 01:48:33 + > @@ -0,0 +1,19 @@ > +2009-11-28 Vladimir Serbinenko > + > + Multiboot support on i386-efi. > + > + * conf/i386-efi.rmk (pkglib_MODULES): Add multiboot.mod. > + (multiboot_mod_SOURCES): New variable. > + (multiboot_mod_CFLAGS): Likewise. > + (multiboot_mod_LDFLAGS): Likewise. > + (multiboot_mod_ASFLAGS): Likewise. > + * include/grub/i386/multiboot.h (grub_multiboot_real_boot): Explicitly > + declare as regparm (3). > + (grub_multiboot2_real_boot): Likewise. > + (grub_multiboot_boot): Finish boot services. > + (grub_fill_multiboot_mmap): Explicitly parse memory map types. > + (grub_multiboot): Declare as noreturn to avoid finishing console. > + * loader/multiboot_loader.c (grub_cmd_multiboot_loader): Enable > + multiboot1 on i386-efi and disable multiboot2 on this platform. > + (grub_cmd_module_loader): Likewise. Could the EFI parts be split into a separate patch? I definitely want both things, but they're separate changes, would be good to have the additional granularity if possible. -- Robert Millan "Be the change you want to see in the world" -- Gandhi ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Multiboot ammendment: non-VBE video
Hi, I committed your last patch with some minor stylistic adjustments, plus your changes to the example kernel. -- Robert Millan "Be the change you want to see in the world" -- Gandhi ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Multiboot ammendment: non-VBE video
Robert Millan wrote:
>
>> Bootloader will use a mode it
>> chooses. Perhaps we should remove recommended mode fields from the spec
>> altogether or make them somehow optional
>>
>
> Is that important? I'm hesitant to do that untill we have better
> understanding
> on what lead to this decision.
>
>>>
>>>
>> It is useful. It allows payload to say: "I'm ok with video mode but
>> prefer text one"
>>
>
> Oh, I think I missunderstood what "EGA-standard text mode" means. Is this
> the same text mode that survived to this day, and is known in GRUB codebase
> as "vga_text"?
>
>
Yes
>>> Perhaps it would be simpler for us to arrange it so that flags 11 and 12
>>> can't be used at the same time. We could just say that flag 11 is reserved
>>> and unused, and then put these declarations in the offset that used to be
>>> for
>>> VBE. IIRC there were no possible sections after VBE, so the Framebuffer
>>> section size wouldn't be constrained by that.
>>>
>>> But if you prefer to keep flag 11 operational, I don't object. I would
>>> probably object to GRUB implementing it though.
>>>
>>>
>>>
>> If payload wants to use VBE it will. I think that providing this
>> informtion saves payload a trip to real mode. So this way we encourage
>> saner real-mode-free OS design.
>>
>
> I'd rather encourage them to use modern flag 12 instead. In any case, it
> doesn't to keep flag 11 as part of the standard as long as it's optional.
> I'm still not convinced GRUB should implement it, but that's a separate
> discussion.
>
>
Flag 12 doesn't allow to e.g. change the resolution or do the double
buffering.
>> Do you think it would be useful to make flag 12 structure describe EGA
>> text too? I attach new diff for multiboot.texi. If it's approved it
>> should be simple to implement in grub2 and example kernel
>>
>
> You forgot to attach it.
>
>
Fixed
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'doc/multiboot.texi'
--- doc/multiboot.texi 2010-01-01 20:02:24 +
+++ doc/multiboot.texi 2010-01-04 19:32:13 +
@@ -477,9 +477,7 @@
All of the graphics fields are enabled by flag bit 2. They specify the
preferred graphics mode. Note that that is only a @emph{recommended}
-mode by the OS image. If the mode exists, the boot loader should set
-it, when the user doesn't specify a mode explicitly. Otherwise, the
-boot loader should fall back to a similar mode, if available.
+mode by the OS image. Boot loader may also choose another mode if it sees fit.
The meaning of each is as follows:
@@ -488,7 +486,9 @@
Contains @samp{0} for linear graphics mode or @samp{1} for
EGA-standard text mode. Everything else is reserved for future
expansion. Note that the boot loader may set a text mode, even if this
-field contains @samp{0}.
+field contains @samp{0}. If video adapter doesn't support EGA text mode or
+bootloader doesn't know how to initialise this mode it may set video
+mode even if field contains @samp{1}
@item width
Contains the number of the columns. This is specified in pixels in a
@@ -635,6 +635,15 @@
84 | vbe_interface_off |
86 | vbe_interface_len |
+---+
+88 | framebuffer_addr |(present if flags[12] is set)
+96 | framebuffer_pitch |
+100 | framebuffer_width |
+104 | framebuffer_height|
+108 | framebuffer_bpp |
+109 | framebuffer_type |
+110-115 | color_info|
++---+
+
@end group
@end example
@@ -911,9 +920,7 @@
@uref{http://www.microsoft.com/hwdev/busbios/amp_12.htm, Advanced Power
Management (APM) BIOS Interface Specification}, for more information.
-If bit 11 in the @samp{flags} is set, the graphics table is available.
-This must only be done if the kernel has indicated in the
-...@samp{multiboot Header} that it accepts a graphics mode.
+If bit 11 in the @samp{flags} is set, the @sc{vbe} table is available.
The fields @samp{vbe_control_info} and @samp{vbe_mode_info} contain
the physical addresses of @sc{vbe} control information returned by the
@@ -935,6 +942,44 @@
Multiboot boot loaders may simulate @sc{vbe} on n...@sc{vbe} modes, as
if they were @sc{vbe} modes.
+If bit 12 in the @samp{flags} is set, the @sc{Framebuffer} table is available.
+
+The field @samp{framebuffer_addr} contains framebuffer physical address. This field is 64-bit wide but bootloader @dfn{should} set it under 4GiB if possible for compatibility with payloads which aren't aware of PAE or amd64. The field @samp{framebuffer_pitch} contains pitch in bytes. The fields @samp{framebuffer_width}, @samp{framebuffer_height} contain framebuffer dimensions in pixels. The field @samp{framebuffer_bpp} contains number of bits per pixel. If @samp{framebuffer_type} is set to 0 it means indexed color. In this case color_info is defined as follows:
+...@example
+...@group
++--+
+110 | framebuffer_palette_addr |
+114 | frameb
Re: [RFC] Multiboot ammendment: non-VBE video
On Mon, Jan 04, 2010 at 08:35:38PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> Robert Millan wrote:
> >
> >> + .long 0
> >> + .long 1024
> >> + .long 768
> >> + .long 32
> >>
> >
> > Maybe better to use 640x480 instead? Not everyone has a large display.
> >
> >
> It's only a recommended resolution.
Ok then, no big deal.
> Bootloader will use a mode it
> chooses. Perhaps we should remove recommended mode fields from the spec
> altogether or make them somehow optional
Is that important? I'm hesitant to do that untill we have better understanding
on what lead to this decision.
> >> /* The bits in the required part of flags field we don't support. */
> >> -#define MULTIBOOT_UNSUPPORTED 0xfffc
> >> +#define MULTIBOOT_UNSUPPORTED 0xfff8
> >>
> >
> > Shouldn't this be 0xeffc ? (0xfffc & ~0x1000)
> >
> >
> AOUT_KLUDGE field is 0x1 and not 0x1000
But that's a completely different bit? I'm a bit confused.
Btw, as you pointed out on IRC, MULTIBOOT_UNSUPPORTED is a GRUB-specific
mask and shouldn't be part of anyway.
> >> preferred graphics mode. Note that that is only a @emph{recommended}
> >> mode by the OS image. If the mode exists, the boot loader should set
> >> it, when the user doesn't specify a mode explicitly. Otherwise, the
> >> -boot loader should fall back to a similar mode, if available.
> >> +boot loader should fall back to a similar mode, if available. Boot loader
> >> +may also choose another mode if it sees fit.
> >>
> >
> > I agree with changing this, but the phrases seem to contradict each other.
> > If
> > the mode exists, what should bootloader do?
> >
> > I suggest we remove from "If the mode exists..." untill
> > "...if available", leaving your "Boot loader may also..." only.
> >
> >
> Actually they were contradicting because "should" means that loader may
> choose not to follow the rule
Sorry, my oversight. Well it is redundant, not contradictory. I didn't
express it properly :-) (some part of my brain doesn't play well with the
rest).
> >> Contains @samp{0} for linear graphics mode or @samp{1} for
> >> EGA-standard text mode. Everything else is reserved for future
> >> expansion. Note that the boot loader may set a text mode, even if this
> >> -field contains @samp{0}.
> >> +field contains @samp{0}. If video adapter doesn't support EGA text mode or
> >> +bootloader doesn't know how to initialise this mode it may set video
> >> +mode even if field contains @samp{1}
> >>
> >
> > If the EGA option is obsolete/useless, I'd just make it:
> >
> > Reserved for backward compatibility. Always contains @samp{0}.
> >
> > and schedule it for removal in next major version.
> >
> >
> It is useful. It allows payload to say: "I'm ok with video mode but
> prefer text one"
Oh, I think I missunderstood what "EGA-standard text mode" means. Is this
the same text mode that survived to this day, and is known in GRUB codebase
as "vga_text"?
> > Perhaps it would be simpler for us to arrange it so that flags 11 and 12
> > can't be used at the same time. We could just say that flag 11 is reserved
> > and unused, and then put these declarations in the offset that used to be
> > for
> > VBE. IIRC there were no possible sections after VBE, so the Framebuffer
> > section size wouldn't be constrained by that.
> >
> > But if you prefer to keep flag 11 operational, I don't object. I would
> > probably object to GRUB implementing it though.
> >
> >
> If payload wants to use VBE it will. I think that providing this
> informtion saves payload a trip to real mode. So this way we encourage
> saner real-mode-free OS design.
I'd rather encourage them to use modern flag 12 instead. In any case, it
doesn't to keep flag 11 as part of the standard as long as it's optional.
I'm still not convinced GRUB should implement it, but that's a separate
discussion.
> Do you think it would be useful to make flag 12 structure describe EGA
> text too? I attach new diff for multiboot.texi. If it's approved it
> should be simple to implement in grub2 and example kernel
You forgot to attach it.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Multiboot ammendment: non-VBE video
On Sun, Jan 3, 2010 at 10:35 AM, Isaac Dupree
wrote:
> Robert Millan wrote:
>>>
>>> In this case color_info is defined as following:
>>
>> I'd appreciate if a native English speaker confirms this, but I believe
>> this should say "as follows" (same for the other instances of this
>> construct).
>
> "as follows" reads naturally to me, as a native speaker (also checked:
> online dictionaries mention the phrase "as follows" without saying it's
> specific to my area -- northeast U.S. -- so I think it's right to use)
+1 for as follows
>
>>> +...@samp{framebuffer_palette_addr} contains address of array of
>>> @samp{framebuffer_palette_num_colors} following structures:
>>
>> There seems to be some word missing here.
>
> "the following structures"?
> "as follows" would also work well if "structures" isn't an important word to
> keep?
> wait, it's like saying "array of 3 following structures", each of the same
> type. hmm. "@samp{framebuffer_palette_num_colors} structures as follows"?
How about this?
XYZZY contains _the_ address of _an_ array of N structures which follow
>
> -Isaac
>
>
> ___
> 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
Re: [RFC] Multiboot ammendment: non-VBE video
Robert Millan wrote:
>
>> +.long 0
>> +.long 1024
>> +.long 768
>> +.long 32
>>
>
> Maybe better to use 640x480 instead? Not everyone has a large display.
>
>
It's only a recommended resolution. Bootloader will use a mode it
chooses. Perhaps we should remove recommended mode fields from the spec
altogether or make them somehow optional
>> /* The bits in the required part of flags field we don't support. */
>> -#define MULTIBOOT_UNSUPPORTED 0xfffc
>> +#define MULTIBOOT_UNSUPPORTED 0xfff8
>>
>
> Shouldn't this be 0xeffc ? (0xfffc & ~0x1000)
>
>
AOUT_KLUDGE field is 0x1 and not 0x1000
>> === modified file 'doc/multiboot.texi'
>> --- doc/multiboot.texi 2010-01-01 20:02:24 +
>> +++ doc/multiboot.texi 2010-01-02 16:58:33 +
>> @@ -479,7 +479,8 @@
>> preferred graphics mode. Note that that is only a @emph{recommended}
>> mode by the OS image. If the mode exists, the boot loader should set
>> it, when the user doesn't specify a mode explicitly. Otherwise, the
>> -boot loader should fall back to a similar mode, if available.
>> +boot loader should fall back to a similar mode, if available. Boot loader
>> +may also choose another mode if it sees fit.
>>
>
> I agree with changing this, but the phrases seem to contradict each other. If
> the mode exists, what should bootloader do?
>
> I suggest we remove from "If the mode exists..." untill
> "...if available", leaving your "Boot loader may also..." only.
>
>
Actually they were contradicting because "should" means that loader may
choose not to follow the rule
>> @@ -488,7 +489,9 @@
>> Contains @samp{0} for linear graphics mode or @samp{1} for
>> EGA-standard text mode. Everything else is reserved for future
>> expansion. Note that the boot loader may set a text mode, even if this
>> -field contains @samp{0}.
>> +field contains @samp{0}. If video adapter doesn't support EGA text mode or
>> +bootloader doesn't know how to initialise this mode it may set video
>> +mode even if field contains @samp{1}
>>
>
> If the EGA option is obsolete/useless, I'd just make it:
>
> Reserved for backward compatibility. Always contains @samp{0}.
>
> and schedule it for removal in next major version.
>
>
It is useful. It allows payload to say: "I'm ok with video mode but
prefer text one"
>> 84 | vbe_interface_off |
>> 86 | vbe_interface_len |
>> +---+
>> +88 | framebuffer_addr |(present if flags[12] is set)
>> +96 | framebuffer_pitch |
>> +100 | framebuffer_width |
>> +104 | framebuffer_height|
>> +108 | framebuffer_bpp |
>> +109 | framebuffer_type |
>> +110-115 | color_info|
>>
>
> Perhaps it would be simpler for us to arrange it so that flags 11 and 12
> can't be used at the same time. We could just say that flag 11 is reserved
> and unused, and then put these declarations in the offset that used to be for
> VBE. IIRC there were no possible sections after VBE, so the Framebuffer
> section size wouldn't be constrained by that.
>
> But if you prefer to keep flag 11 operational, I don't object. I would
> probably object to GRUB implementing it though.
>
>
If payload wants to use VBE it will. I think that providing this
informtion saves payload a trip to real mode. So this way we encourage
saner real-mode-free OS design.
Do you think it would be useful to make flag 12 structure describe EGA
text too? I attach new diff for multiboot.texi. If it's approved it
should be simple to implement in grub2 and example kernel
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Multiboot ammendment: non-VBE video
Robert Millan wrote:
In this case color_info is defined as following:
I'd appreciate if a native English speaker confirms this, but I believe
this should say "as follows" (same for the other instances of this
construct).
"as follows" reads naturally to me, as a native speaker (also checked:
online dictionaries mention the phrase "as follows" without saying it's
specific to my area -- northeast U.S. -- so I think it's right to use)
+...@samp{framebuffer_palette_addr} contains address of array of
@samp{framebuffer_palette_num_colors} following structures:
There seems to be some word missing here.
"the following structures"?
"as follows" would also work well if "structures" isn't an important
word to keep?
wait, it's like saying "array of 3 following structures", each of the
same type. hmm. "@samp{framebuffer_palette_num_colors} structures as
follows"?
-Isaac
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Multiboot ammendment: non-VBE video
On Sat, Jan 02, 2010 at 07:26:08PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> I followed your suggestions. I attach new draft together with drawing of
> a blue diagonal line in example kernel (it would be way better to make
> it use it for output but it's intended to just show how to use passed
> info). I also attach an implementation of multiboot on EFI which uses
> this draft. Note that this ammendment is nothing EFI-specific and can be
> used with any linear framebuffer driver. The only reason it's in the
> same patch is because it was the branch in which I was working on
> multiboot improvements and haven't yet splitted individual changes yet
Excellent. I'll review the Multiboot part first.
> /* The flags for the Multiboot header. */
> #ifdef __ELF__
> -# define MULTIBOOT_HEADER_FLAGS 0x0003
> +# define MULTIBOOT_HEADER_FLAGS 0x0007
> #else
> -# define MULTIBOOT_HEADER_FLAGS 0x00010003
> +# define MULTIBOOT_HEADER_FLAGS 0x00010007
> #endif
This was a bit messy. I just replaced it with an ORed macro list. I
should have done this before, but I didn't have time to. Sorry to break
your patch, but it's a trivial fix ;-)
> + .long 0
> + .long 1024
> + .long 768
> + .long 32
Maybe better to use 640x480 instead? Not everyone has a large display.
> /* The bits in the required part of flags field we don't support. */
> -#define MULTIBOOT_UNSUPPORTED0xfffc
> +#define MULTIBOOT_UNSUPPORTED 0xfff8
Shouldn't this be 0xeffc ? (0xfffc & ~0x1000)
> === modified file 'doc/multiboot.texi'
> --- doc/multiboot.texi2010-01-01 20:02:24 +
> +++ doc/multiboot.texi2010-01-02 16:58:33 +
> @@ -479,7 +479,8 @@
> preferred graphics mode. Note that that is only a @emph{recommended}
> mode by the OS image. If the mode exists, the boot loader should set
> it, when the user doesn't specify a mode explicitly. Otherwise, the
> -boot loader should fall back to a similar mode, if available.
> +boot loader should fall back to a similar mode, if available. Boot loader
> +may also choose another mode if it sees fit.
I agree with changing this, but the phrases seem to contradict each other. If
the mode exists, what should bootloader do?
I suggest we remove from "If the mode exists..." untill
"...if available", leaving your "Boot loader may also..." only.
> @@ -488,7 +489,9 @@
> Contains @samp{0} for linear graphics mode or @samp{1} for
> EGA-standard text mode. Everything else is reserved for future
> expansion. Note that the boot loader may set a text mode, even if this
> -field contains @samp{0}.
> +field contains @samp{0}. If video adapter doesn't support EGA text mode or
> +bootloader doesn't know how to initialise this mode it may set video
> +mode even if field contains @samp{1}
If the EGA option is obsolete/useless, I'd just make it:
Reserved for backward compatibility. Always contains @samp{0}.
and schedule it for removal in next major version.
> 84 | vbe_interface_off |
> 86 | vbe_interface_len |
> +---+
> +88 | framebuffer_addr |(present if flags[12] is set)
> +96 | framebuffer_pitch |
> +100 | framebuffer_width |
> +104 | framebuffer_height|
> +108 | framebuffer_bpp |
> +109 | framebuffer_type |
> +110-115 | color_info|
Perhaps it would be simpler for us to arrange it so that flags 11 and 12
can't be used at the same time. We could just say that flag 11 is reserved
and unused, and then put these declarations in the offset that used to be for
VBE. IIRC there were no possible sections after VBE, so the Framebuffer
section size wouldn't be constrained by that.
But if you prefer to keep flag 11 operational, I don't object. I would
probably object to GRUB implementing it though.
> In this case color_info is defined as following:
I'd appreciate if a native English speaker confirms this, but I believe
this should say "as follows" (same for the other instances of this
construct).
> +...@samp{framebuffer_palette_addr} contains address of array of
> @samp{framebuffer_palette_num_colors} following structures:
There seems to be some word missing here.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Multiboot ammendment: non-VBE video
Robert Millan wrote:
> On Mon, Dec 28, 2009 at 01:07:10PM +0100, Vladimir 'φ-coder/phcoder'
> Serbinenko wrote:
>
>> Robert Millan wrote:
>>
>>> On Tue, Sep 01, 2009 at 05:37:11PM +0200, Vladimir 'phcoder' Serbinenko
>>> wrote:
>>>
>>>
Hello. I'm implementing video part of multiboot specification.
Currently the only defined interface is for providing VBE info. I
propose following way to set fields if video is non VBE:
vbe_control_info=0x
When vbe_control_info is set to 0x all VBE-specific fields are
invalid
vbe_mode set to 0x
vbe_interface_seg=0x
vbe_interface_off=0x
vbe_interface_len=0xff
vbe_mode_info points to structure similar to vbe_mode_info but with
all vbe-specific fields set to zero. Remaining (valid) fields are
(full structur is in include/grub/i386/pc/vbe.h)
>>> This seems like one of these cases in which legacy gets in the way. Why
>>> don't we just replace the legacy structure with something that doesn't need
>>> dummy fields?
>>>
>>>
>> Actually it seems like we already define possible dummy fields if
>> vbe_interface isn't available.
>>
>
> Yes. That's the case for vbe_interface_* fields. But extending this to
> vbe_control_info and vbe_mode_info is backward-incompatible.
>
> I don't object to backward-incompatible changes, but I would expect that
> when we make one, we get the benefit of a clean, legacy-free interface. In
> this case we carry on with legacy baggage to archieve half-way backward
> compatibility.
>
> In purely practical terms, all of this only has a minimal effect. GRUB Legacy
> didn't implement these extensions, and GRUB 2 hasn't yet, so use of this
> feature in loadees isn't widespread. But it has a major impact when it comes
> to reputation. If we make incompatible changes in the text, we should be
> honest about it. I don't want people to think they can't rely on Multiboot
> because its maintainers sometimes stretch the definitions in ways not
> permitted by the text.
>
> Since it's obvious we want to change something (rather than implement
> VBE-specific extensions), I propose we start with:
>
> -If bit 11 in the @samp{flags} is set, the graphics table is available.
> +If bit 12 in the @samp{flags} is set, the graphics table is available.
>
> at this point, we can change anything we like.
>
>
I followed your suggestions. I attach new draft together with drawing of
a blue diagonal line in example kernel (it would be way better to make
it use it for output but it's intended to just show how to use passed
info). I also attach an implementation of multiboot on EFI which uses
this draft. Note that this ammendment is nothing EFI-specific and can be
used with any linear framebuffer driver. The only reason it's in the
same patch is because it was the branch in which I was working on
multiboot improvements and haven't yet splitted individual changes yet
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'doc/boot.S'
--- doc/boot.S 2009-12-24 13:34:49 +
+++ doc/boot.S 2010-01-02 17:13:52 +
@@ -30,9 +30,9 @@
/* The flags for the Multiboot header. */
#ifdef __ELF__
-# define MULTIBOOT_HEADER_FLAGS 0x0003
+# define MULTIBOOT_HEADER_FLAGS 0x0007
#else
-# define MULTIBOOT_HEADER_FLAGS 0x00010003
+# define MULTIBOOT_HEADER_FLAGS 0x00010007
#endif
.text
@@ -64,7 +64,17 @@
.long _end
/* entry_addr */
.long multiboot_entry
-#endif /* ! __ELF__ */
+#else /* ! __ELF__ */
+ .long 0
+ .long 0
+ .long 0
+ .long 0
+ .long 0
+#endif /* __ELF__ */
+ .long 0
+ .long 1024
+ .long 768
+ .long 32
multiboot_entry:
/* Initialize the stack pointer. */
=== modified file 'doc/kernel.c'
--- doc/kernel.c 2009-12-24 14:25:44 +
+++ doc/kernel.c 2010-01-02 17:04:15 +
@@ -150,6 +150,87 @@
mmap->len & 0x,
(unsigned) mmap->type);
}
+
+ /* Draw diagonal blue line. */
+ if (CHECK_FLAG (mbi->flags, 12))
+{
+ multiboot_uint32_t color;
+ unsigned i;
+ void *fb = (void *) (unsigned long) mbi->framebuffer_addr;
+
+ switch (mbi->framebuffer_type)
+ {
+ case MULTIBOOT_FRAMEBUFFER_TYPE_INDEXED:
+ {
+ unsigned best_distance, distance;
+ struct multiboot_color *palette;
+
+ palette = (struct multiboot_color *) mbi->framebuffer_palette_addr;
+
+ color = 0;
+ best_distance = 4*256*256;
+
+ for (i = 0; i < mbi->framebuffer_palette_num_colors; i++)
+ {
+ distance = (0xff - palette[i].blue) * (0xff - palette[i].blue)
+ + palette[i].red * palette[i].red
+ + palette[i].green * palette[i].green;
+ if (distance < best_distance)
+ {
+ color = i;
+ best_distance = distance;
+ }
+ }
+ }
+ break;
+
+ case MULTIBOOT_FRAMEBUFFER_TYPE_RGB:
+ color = ((1 << mbi->framebuffer_blue_mask_size) - 1)
+ << mbi->framebuffer_blue_field_position;
+ break;
+
+ default:
+ color = 0x;
Re: [RFC] Multiboot ammendment: non-VBE video
On Mon, Dec 28, 2009 at 01:07:10PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> Robert Millan wrote:
> > On Tue, Sep 01, 2009 at 05:37:11PM +0200, Vladimir 'phcoder' Serbinenko
> > wrote:
> >
> >> Hello. I'm implementing video part of multiboot specification.
> >> Currently the only defined interface is for providing VBE info. I
> >> propose following way to set fields if video is non VBE:
> >> vbe_control_info=0x
> >> When vbe_control_info is set to 0x all VBE-specific fields are
> >> invalid
> >> vbe_mode set to 0x
> >> vbe_interface_seg=0x
> >> vbe_interface_off=0x
> >> vbe_interface_len=0xff
> >> vbe_mode_info points to structure similar to vbe_mode_info but with
> >> all vbe-specific fields set to zero. Remaining (valid) fields are
> >> (full structur is in include/grub/i386/pc/vbe.h)
> >>
> >
> > This seems like one of these cases in which legacy gets in the way. Why
> > don't we just replace the legacy structure with something that doesn't need
> > dummy fields?
> >
> Actually it seems like we already define possible dummy fields if
> vbe_interface isn't available.
Yes. That's the case for vbe_interface_* fields. But extending this to
vbe_control_info and vbe_mode_info is backward-incompatible.
I don't object to backward-incompatible changes, but I would expect that
when we make one, we get the benefit of a clean, legacy-free interface. In
this case we carry on with legacy baggage to archieve half-way backward
compatibility.
In purely practical terms, all of this only has a minimal effect. GRUB Legacy
didn't implement these extensions, and GRUB 2 hasn't yet, so use of this
feature in loadees isn't widespread. But it has a major impact when it comes
to reputation. If we make incompatible changes in the text, we should be
honest about it. I don't want people to think they can't rely on Multiboot
because its maintainers sometimes stretch the definitions in ways not
permitted by the text.
Since it's obvious we want to change something (rather than implement
VBE-specific extensions), I propose we start with:
-If bit 11 in the @samp{flags} is set, the graphics table is available.
+If bit 12 in the @samp{flags} is set, the graphics table is available.
at this point, we can change anything we like.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Multiboot ammendment: non-VBE video
Robert Millan wrote:
> On Tue, Sep 01, 2009 at 05:37:11PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>
>> Hello. I'm implementing video part of multiboot specification.
>> Currently the only defined interface is for providing VBE info. I
>> propose following way to set fields if video is non VBE:
>> vbe_control_info=0x
>> When vbe_control_info is set to 0x all VBE-specific fields are
>> invalid
>> vbe_mode set to 0x
>> vbe_interface_seg=0x
>> vbe_interface_off=0x
>> vbe_interface_len=0xff
>> vbe_mode_info points to structure similar to vbe_mode_info but with
>> all vbe-specific fields set to zero. Remaining (valid) fields are
>> (full structur is in include/grub/i386/pc/vbe.h)
>>
>
> This seems like one of these cases in which legacy gets in the way. Why
> don't we just replace the legacy structure with something that doesn't need
> dummy fields?
>
Actually it seems like we already define possible dummy fields if
vbe_interface isn't available. vbe_mode_info although contains some vbe
callback info and framebuffer information info. We need only second. My
idea was that payloads that only use info for framebuffer may be readily
working on non-VBE. Alternatively we may define a structure which
contains only framebuffer info. This would avoid the requirement to set
vbe display line to 0 before calling the payload. The draft I have
locally is the following:
=== modified file 'docs/multiboot.texi'
--- docs/multiboot.texi2008-09-03 20:15:15 +
+++ docs/multiboot.texi2009-12-17 20:04:47 +
@@ -479,7 +479,8 @@
preferred graphics mode. Note that that is only a @emph{recommended}
mode by the OS image. If the mode exists, the boot loader should set
it, when the user doesn't specify a mode explicitly. Otherwise, the
-boot loader should fall back to a similar mode, if available.
+boot loader should fall back to a similar mode, if available. Boot loader
+may also choose another mode if it sees fit.
The meaning of each is as follows:
@@ -488,7 +489,9 @@
Contains @samp{0} for linear graphics mode or @samp{1} for
EGA-standard text mode. Everything else is reserved for future
expansion. Note that the boot loader may set a text mode, even if this
-field contains @samp{0}.
+field contains @samp{0}. If video adapter doesn't support EGA text mode or
+bootloader doesn't know how to initialise this mode it may set video
+mode even if field contains @samp{1}
@item width
Contains the number of the columns. This is specified in pixels in a
@@ -917,16 +920,62 @@
Management (APM) BIOS Interface Specification}, for more information.
If bit 11 in the @samp{flags} is set, the graphics table is available.
-This must only be done if the kernel has indicated in the
-...@samp{multiboot Header} that it accepts a graphics mode.
The fields @samp{vbe_control_info} and @samp{vbe_mode_info} contain
the physical addresses of @sc{vbe} control information returned by the
@sc{vbe} Function 00h and @sc{vbe} mode information returned by the
-...@sc{vbe} Function 01h, respectively.
+...@sc{vbe} Function 01h, respectively. In case of n...@sc{vbe} video driver
+...@samp{vbe_control_info} contains zero and @samp{vbe_mode_info} points
to the
+following 256-byte structure:
+
+...@example
+...@group
++--+
+0 | flags|
+2 | zeros|
+16 | pitch|
+18 | width|
+20 | height |
+22 | zeros|
+25 | bits per pixel |
+26 | zeros|
+27 | memory model |
+28 | zeros|
+31 | red mask size|
+32 | red field position |
+33 | green mask size |
+34 | green field position |
+35 | blue mask size |
+36 | blue field position |
+37 | alpha mask size |
+38 | alpha field position |
+39 | zero |
+40 | framebuffer address |
+44 | zero |
+50 | pitch|
+52 | zero |
+54 | red mask size|
+55 | red field position |
+56 | green mask size |
+57 | green field position |
+58 | blue mask size |
+59 | blue field position |
+60 | alpha mask size |
+61 | alpha field position |
+62 | zeros|
++--+
+...@end group
+...@end example
+
+All fields have the same meaning as the corresponding VBE mode info
+structure except fields marked as zeros which are zero-filled.
+
+If video is a linear framebuffer boot loader has to ensure that
+displayed region starts at offset @samp{0} of linear framebuffer.
The field @samp{vbe_mode} indicates current video mode in the format
-specified in @sc{vbe} 3.0.
+specified in @sc{vbe} 3.0. In case of n...@sc{vbe} video driver
+...@samp{vbe_mode} contains 0x.
The rest fields @samp{vbe_interface_seg}, @samp{vbe_in
Re: [RFC] Multiboot ammendment: non-VBE video
On Tue, Sep 01, 2009 at 05:37:11PM +0200, Vladimir 'phcoder' Serbinenko wrote: > Hello. I'm implementing video part of multiboot specification. > Currently the only defined interface is for providing VBE info. I > propose following way to set fields if video is non VBE: > vbe_control_info=0x > When vbe_control_info is set to 0x all VBE-specific fields are invalid > vbe_mode set to 0x > vbe_interface_seg=0x > vbe_interface_off=0x > vbe_interface_len=0xff > vbe_mode_info points to structure similar to vbe_mode_info but with > all vbe-specific fields set to zero. Remaining (valid) fields are > (full structur is in include/grub/i386/pc/vbe.h) This seems like one of these cases in which legacy gets in the way. Why don't we just replace the legacy structure with something that doesn't need dummy fields? -- Robert Millan "Be the change you want to see in the world" -- Gandhi ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[RFC] Multiboot ammendment: non-VBE video
Hello. I'm implementing video part of multiboot specification. Currently the only defined interface is for providing VBE info. I propose following way to set fields if video is non VBE: vbe_control_info=0x When vbe_control_info is set to 0x all VBE-specific fields are invalid vbe_mode set to 0x vbe_interface_seg=0x vbe_interface_off=0x vbe_interface_len=0xff vbe_mode_info points to structure similar to vbe_mode_info but with all vbe-specific fields set to zero. Remaining (valid) fields are (full structur is in include/grub/i386/pc/vbe.h) grub_uint16_t bytes_per_scan_line; grub_uint16_t x_resolution; grub_uint16_t y_resolution; grub_uint8_t bits_per_pixel; grub_uint8_t memory_model; grub_uint8_t red_mask_size; grub_uint8_t red_field_position; grub_uint8_t green_mask_size; grub_uint8_t green_field_position; grub_uint8_t blue_mask_size; grub_uint8_t blue_field_position; grub_uint8_t rsvd_mask_size; grub_uint8_t rsvd_field_position; grub_uint8_t direct_color_mode_info; grub_vbe_physptr_t phys_base_addr; grub_uint16_t lin_bytes_per_scan_line; grub_uint8_t lin_red_mask_size; grub_uint8_t lin_red_field_position; grub_uint8_t lin_green_mask_size; grub_uint8_t lin_green_field_position; grub_uint8_t lin_blue_mask_size; grub_uint8_t lin_blue_field_position; grub_uint8_t lin_rsvd_mask_size; grub_uint8_t lin_rsvd_field_position; -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
