grub-dumpbios

grub-dumpbios

[Robert Millan]

Hi,

Do we really need to ship a specific utility just to run two commands?

  dd if=/dev/mem of=${output_dir}vbios.bin bs=65536 skip=12 count=1
  dd if=/dev/mem of=${output_dir}int10.bin bs=4 skip=16 count=1

Sounds like user will need to read some documentation in order to figure
out what grub-dumpbios is good for, and what to do with those files, so
why not just document the commands there instead?  (e.g. in the wiki or
so)

-- 
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: grub-dumpbios

[Bean]

Hi,

Perhaps we could incorporate them in grub-update/grub-install, I guess
there should be no harm adding two files in /boot/grub.

On Tue, May 5, 2009 at 3:27 AM, Robert Millan <rmh@aybabtu.com> wrote:
>
> Hi,
>
> Do we really need to ship a specific utility just to run two commands?
>
>  dd if=/dev/mem of=${output_dir}vbios.bin bs=65536 skip=12 count=1
>  dd if=/dev/mem of=${output_dir}int10.bin bs=4 skip=16 count=1
>
> Sounds like user will need to read some documentation in order to figure
> out what grub-dumpbios is good for, and what to do with those files, so
> why not just document the commands there instead?  (e.g. in the wiki or
> so)
>
> --
> 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."
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Bean

Re: grub-dumpbios

[Stefan Reinauer]

On 04.05.2009 21:27 Uhr, Robert Millan wrote:
> Hi,
>
> Do we really need to ship a specific utility just to run two commands?
>
>   dd if=/dev/mem of=${output_dir}vbios.bin bs=65536 skip=12 count=1
>   dd if=/dev/mem of=${output_dir}int10.bin bs=4 skip=16 count=1
>
> Sounds like user will need to read some documentation in order to figure
> out what grub-dumpbios is good for, and what to do with those files, so
> why not just document the commands there instead?  (e.g. in the wiki or
> so)
>
>   
As a side note: On many machines dumping the VGA option rom like that
does not produce good option rom images. Many option roms are
self-modifying and the above method only dumps the modified variants of
the ROMs that are normally not good for "POSTing" a graphics card
anymore. They're still good for other purposes though I guess.

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info@coresystems.de  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

Re: grub-dumpbios

[Robert Millan]

On Tue, May 05, 2009 at 03:57:17AM +0800, Bean wrote:
> Hi,
> 
> Perhaps we could incorporate them in grub-update/grub-install, I guess
> there should be no harm adding two files in /boot/grub.

Please don't.  This is really corner case;  I at least wouldn't want GRUB
to install non-free blobs in /boot/grub automagically.

(Those blobs were already in the hardware, so GRUB is not responsible for
them, but still...)

Is this use case documented somewhere (e.g. in the wiki)?  Then users who
need it can learn about the procedure from the same place.  Also ...

On Mon, May 04, 2009 at 10:28:52PM +0200, Stefan Reinauer wrote:
> As a side note: On many machines dumping the VGA option rom like that
> does not produce good option rom images. Many option roms are
> self-modifying and the above method only dumps the modified variants of
> the ROMs that are normally not good for "POSTing" a graphics card
> anymore. They're still good for other purposes though I guess.

... as Stefan points out (thanks Stefan) this may not be so
straightforwarded.  I don't think this kind of tweaking is suitable
for a setup that "Joe user" will get by default.

Btw, if the video rom can be obtained directly from memory, why doesn't
GRUB read it in runtime instead?

-- 
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: grub-dumpbios

[step21]

It is kinda documented on ubuntu-forums I think ... and maybe on the
list. (here) When ppl were either asked to test it or reported their
findings. I think the main use case is booting linux directly from
efi, without bios emulation mode/legacy mode. This primarily applies
to macs, though it might apply to non-mac efi machines too.
Concerning "Joe User": If someone really wants to install linux on
their mac/efi machine they're likely o.k. to run a shell script to get
a binary blob (if they want graphics accel that is)
As I see it the main reason to put this in a script is really that it
saves you unncessary trips to the wiki or other documentation sources,
where you'd end up copy n' pasting the command anyway.
So from an "end user" perspective, I'd think it'd be nice to keep it.
If/why it can't be read by grub directly I don't know. Most likely I
think because it needs a properly "initialized" video bios to work,
which is not present when grub is active.

>
> Is this use case documented somewhere (e.g. in the wiki)?  Then users who
> need it can learn about the procedure from the same place.  Also ...
>
> On Mon, May 04, 2009 at 10:28:52PM +0200, Stefan Reinauer wrote:
>> As a side note: On many machines dumping the VGA option rom like that
>> does not produce good option rom images. Many option roms are
>> self-modifying and the above method only dumps the modified variants of
>> the ROMs that are normally not good for "POSTing" a graphics card
>> anymore. They're still good for other purposes though I guess.
>
> ... as Stefan points out (thanks Stefan) this may not be so
> straightforwarded.  I don't think this kind of tweaking is suitable
> for a setup that "Joe user" will get by default.
>
> Btw, if the video rom can be obtained directly from memory, why doesn't
> GRUB read it in runtime instead?
>
> --
> 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."
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: grub-dumpbios

[Bean]

On Tue, May 5, 2009 at 4:39 AM, Robert Millan <rmh@aybabtu.com> wrote:
> On Tue, May 05, 2009 at 03:57:17AM +0800, Bean wrote:
>> Hi,
>>
>> Perhaps we could incorporate them in grub-update/grub-install, I guess
>> there should be no harm adding two files in /boot/grub.
>
> Please don't.  This is really corner case;  I at least wouldn't want GRUB
> to install non-free blobs in /boot/grub automagically.
>
> (Those blobs were already in the hardware, so GRUB is not responsible for
> them, but still...)
>
> Is this use case documented somewhere (e.g. in the wiki)?  Then users who
> need it can learn about the procedure from the same place.  Also ...
>

Hi,

I've documented the usage of grub-dumpbios in wiki page:

http://grub.enbug.org/TestingOnMacbook

The commands can be placed there as well. I personally doesn't mind,
but perhaps it would be easier for casual user to use a command
instead of typing the dd's directly.

> On Mon, May 04, 2009 at 10:28:52PM +0200, Stefan Reinauer wrote:
>> As a side note: On many machines dumping the VGA option rom like that
>> does not produce good option rom images. Many option roms are
>> self-modifying and the above method only dumps the modified variants of
>> the ROMs that are normally not good for "POSTing" a graphics card
>> anymore. They're still good for other purposes though I guess.
>
> ... as Stefan points out (thanks Stefan) this may not be so
> straightforwarded.  I don't think this kind of tweaking is suitable
> for a setup that "Joe user" will get by default.
>
> Btw, if the video rom can be obtained directly from memory, why doesn't
> GRUB read it in runtime instead?

Actually, the modified rom is what we need, as it contains information
such as DDC table which is detected on POST, the original rom is not
very useful in this respect.

A better approach would be to fetch the rom from pci, then emulate the
POST process in grub2. But this need to port code from x86emu.

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



-- 
Bean

Re: grub-dumpbios

[Peter Cros]

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

On Tue, May 5, 2009 at 3:45 PM, Bean <bean123ch@gmail.com> wrote:

> Hi,
>
> I've documented the usage of grub-dumpbios in wiki page:
>
> http://grub.enbug.org/TestingOnMacbook
>
> The commands can be placed there as well. I personally doesn't mind,
> but perhaps it would be easier for casual user to use a command
> instead of typing the dd's directly.
>
Hi,

It would be useful to have the commands engraved in the wiki, then it won't
matter what happens to grub-dumpbios, although it was handy to have it.

Cros (pxw)

[-- Attachment #2: Type: text/html, Size: 922 bytes --]

Re: grub-dumpbios

[Vladimir 'phcoder' Serbinenko]

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

> ... as Stefan points out (thanks Stefan) this may not be so
> > straightforwarded.  I don't think this kind of tweaking is suitable
> > for a setup that "Joe user" will get by default.
> >
> > Btw, if the video rom can be obtained directly from memory, why doesn't
> > GRUB read it in runtime instead?
>
> Actually, the modified rom is what we need, as it contains information
> such as DDC table which is detected on POST, the original rom is not
> very useful in this respect.
>
> A better approach would be to fetch the rom from pci, then emulate the
> POST process in grub2. But this need to port code from x86emu.
>
Default boot.efi passes to OSX kernel a blob device-properties containing
some information about graphic and sound card. I'm nearly sure that it's
retrieved from EFI and have an idea how but am not entirely sure yet. Here
is an example from Florian Idelberger's dump from MBA who kindly permitted
me to publish it
device-path (like in EFI specifications): 02 01 0c 00 d0 41 03 0a 00 00 00
00 01 01 06 00 00 02 7f ff 04 00

"saved-timing0"
length: 160
bytes: 13 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 9b 82 07 00 00 00 00
80 9b 82 07 00 00 00 00 80 9b 82 07 00 00 00 00 00 05 00 00 90 01 00 00 10
00 00 00 90 00 00 00 c0 03 00 00 28 00 00 00 01 00 00 00 03 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00

"saved-timing1"
length: 160
bytes: 00 10 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 43 52 04 00 00 00 00
20 43 52 04 00 00 00 00 20 43 52 04 00 00 00 00 00 05 00 00 a0 00 00 00 30
00 00 00 20 00 00 00 20 03 00 00 17 00 00 00 03 00 00 00 06 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00

"saved-config"
length: 256
bytes: 00 00 00 00 01 00 00 00 09 d1 00 00 c4 76 00 00 01 00 00 00 80 9b 82
07 90 06 00 00 00 05 00 00 90 06 00 00 10 05 00 00 a0 05 00 00 e8 03 00 00
c0 03 00 00 e8 03 00 00 c1 03 00 00 c4 03 00 00 00 00 00 00 03 00 00 00 00
00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 13 00
00 80 06 10 00 00 73 9c 00 00 00 00 00 00 20 43 52 04 a0 05 00 00 00 05 00
00 a0 05 00 00 30 05 00 00 50 05 00 00 37 03 00 00 20 03 00 00 37 03 00 00
23 03 00 00 29 03 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02
00 00 00 00 00 00 00 00 00 00 00 1a 00 00 00 00 10 00 80 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

"AAPL,backlight-control"
length: 4
bytes: 01 00 00 00

"AAPL,NumDisplays"
length: 4
bytes: 04 00 00 00

"AAPL,DisplayConfig"
length: 32
bytes: 13 00 00 00 00 00 00 01 21 00 00 00 00 00 00 00 41 00 00 00 00 00 00
00 81 00 00 00 00 00 00 00

"AAPL,HasPanel"
length: 4
bytes: 01 00 00 00

"AAPL,HasLid"
length: 4
bytes: 01 00 00 00

"AAPL,NumFramebuffers"
length: 4
bytes: 02 00 00 00

"AAPL,SelfRefreshSupported"
length: 4
bytes: 01 00 00 00

"AAPL,BacklightRestore"
length: 4
bytes: 01 00 00 00

"AAPL,BacklightMax"
length: 4
bytes: 56 00 00 00

"AAPL,aux-power-connected"
length: 4
bytes: 01 00 00 00

"AAPL01,T1"
length: 4
bytes: 00 00 00 00

"AAPL01,T2"
length: 4
bytes: 01 00 00 00

"AAPL01,T3"
length: 4
bytes: c8 00 00 00

"AAPL01,T4"
length: 4
bytes: c8 00 00 00

"AAPL01,T5"
length: 4
bytes: 01 00 00 00

"AAPL01,T6"
length: 4
bytes: 00 00 00 00

"AAPL01,T7"
length: 4
bytes: 90 01 00 00

"AAPL01,InverterFrequency"
length: 4
bytes: aa 01 00 00

"AAPL01,LinkType"
length: 4
bytes: 00 00 00 00

"AAPL01,DualLink"
length: 4
bytes: 00 00 00 00

"AAPL01,DataJustify"
length: 4
bytes: 01 00 00 00

"AAPL01,LinkFormat"
length: 4
bytes: 00 00 00 00

"AAPL01,PixelFormat"
length: 4
bytes: 00 00 00 00

"AAPL01,Inverter"
length: 4
bytes: 00 00 00 00

"AAPL01,Dither"
length: 4
bytes: 00 00 00 00

"AAPL01,InverterCurrent"
length: 4
bytes: 00 00 00 00

"AAPL01,BacklightIntensity"
length: 4
bytes: 1a 00 00 00

"AAPL01,CurrentDisplay"
length: 4
bytes: 00 00 00 00

"AAPL01,Height"
length: 4
bytes: 20 03 00 00

"AAPL01,Width"
length: 4
bytes: 00 05 00 00

"AAPL01,Depth"
length: 4
bytes: 20 00 00 00

"AAPL01,Refresh"
length: 4
bytes: 3d 00 00 00

"AAPL01,Interlace"
length: 4
bytes: 00 00 00 00

"AAPL01,Stretched"
length: 4
bytes: 00 00 00 00

"AAPL01,EDID"
length: 128
bytes: 00 ff ff ff ff ff ff 00 06 10 73 9c 01 01 01 01 10 11 01 03 80 1d 12
78 0a 90 b5 99 58 52 8e 26 1e 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 52 1c 00 a0 50 20 17 30 30 20 36 00 1e b3 10 00 00 18 00
00 00 01 00 06 10 20 00 00 00 00 00 00 00 00 0a 20 00 00 00 fe 00 42 31 33
33 45 57 30 33 20 56 30 0a 20 00 00 00 fe 00 43 6f 6c 6f 72 20 4c 43 44 0a
20 20 20 00 d4

"AAPL01,IODisplayMode"
length: 4
bytes: 00 10 00 80

"AAPL01,Pipe"
length: 4
bytes: 01 00 00 00

"AAPL01,BootDisplay"
length: 4
bytes: 01 00 00 00

"AAPL01,blackscreen-preferences"
length: 4
bytes: 00 00 00 08

"AAPL00,blackscreen-preferences"
length: 4
bytes: 00 00 00 08


-- 
Regards
Vladimir 'phcoder' Serbinenko

[-- Attachment #2: Type: text/html, Size: 6685 bytes --]

Re: grub-dumpbios

[Vladimir 'phcoder' Serbinenko]

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

On Tue, May 5, 2009 at 2:23 PM, Vladimir 'phcoder' Serbinenko <
phcoder@gmail.com> wrote:

>
>
> > ... as Stefan points out (thanks Stefan) this may not be so
>> > straightforwarded.  I don't think this kind of tweaking is suitable
>> > for a setup that "Joe user" will get by default.
>> >
>> > Btw, if the video rom can be obtained directly from memory, why doesn't
>> > GRUB read it in runtime instead?
>>
>> Actually, the modified rom is what we need, as it contains information
>> such as DDC table which is detected on POST, the original rom is not
>> very useful in this respect.
>>
>> A better approach would be to fetch the rom from pci, then emulate the
>> POST process in grub2. But this need to port code from x86emu.
>>
> Default boot.efi passes to OSX kernel a blob device-properties containing
> some information about graphic and sound card. I'm nearly sure that it's
> retrieved from EFI and have an idea how but am not entirely sure yet.
>

Forgot the most important question: does it help in any way to generate a
suitable dump within grub itself?
-- 
Regards
Vladimir 'phcoder' Serbinenko

[-- Attachment #2: Type: text/html, Size: 1683 bytes --]

Re: grub-dumpbios

[Peter Cros]

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

On Tue, May 5, 2009 at 10:25 PM, Vladimir 'phcoder' Serbinenko <
phcoder@gmail.com> wrote:

>
>
> Forgot the most important question: does it help in any way to generate a
> suitable dump within grub itself?
>

For the user - yes, it avoids the need to use a pc-bios boot to get the
dump.
Or if it improves efi loadbios support for some graphics 3d agp drivers, at
present this is very limited for apple efi. (works for me with ATI fglrx
driver on x86 kernel, but not for nvidia or x86_64).


Cros (pxw)

[-- Attachment #2: Type: text/html, Size: 831 bytes --]

Re: grub-dumpbios

[Vladimir 'phcoder' Serbinenko]

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

On Tue, May 5, 2009 at 4:36 PM, Peter Cros <pxwpxw8@gmail.com> wrote:

>
>
> On Tue, May 5, 2009 at 10:25 PM, Vladimir 'phcoder' Serbinenko <
> phcoder@gmail.com> wrote:
>
>>
>>
>> Forgot the most important question: does it help in any way to generate a
>> suitable dump within grub itself?
>>
>
> For the user - yes, it avoids the need to use a pc-bios boot to get the
> dump.
> Or if it improves efi loadbios support for some graphics 3d agp drivers, at
> present this is very limited for apple efi. (works for me with ATI fglrx
> driver on x86 kernel, but not for nvidia or x86_64).
>
Soory for misunderstanding the actual question was "can device-properties be
used for generating suitable biosdump"

>
>
> Cros (pxw)
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>


-- 
Regards
Vladimir 'phcoder' Serbinenko

[-- Attachment #2: Type: text/html, Size: 1887 bytes --]

Re: grub-dumpbios

[Robert Millan]

On Tue, May 05, 2009 at 01:45:31PM +0800, Bean wrote:
> On Tue, May 5, 2009 at 4:39 AM, Robert Millan <rmh@aybabtu.com> wrote:
> > On Tue, May 05, 2009 at 03:57:17AM +0800, Bean wrote:
> >> Hi,
> >>
> >> Perhaps we could incorporate them in grub-update/grub-install, I guess
> >> there should be no harm adding two files in /boot/grub.
> >
> > Please don't.  This is really corner case;  I at least wouldn't want GRUB
> > to install non-free blobs in /boot/grub automagically.
> >
> > (Those blobs were already in the hardware, so GRUB is not responsible for
> > them, but still...)
> >
> > Is this use case documented somewhere (e.g. in the wiki)?  Then users who
> > need it can learn about the procedure from the same place.  Also ...
> >
> 
> Hi,
> 
> I've documented the usage of grub-dumpbios in wiki page:
> 
> http://grub.enbug.org/TestingOnMacbook
> 
> The commands can be placed there as well. I personally doesn't mind,
> but perhaps it would be easier for casual user to use a command
> instead of typing the dd's directly.

Hi,

I just put the dd commands in that wiki page.  I'm removing grub-dumpbios
from svn as it's no longer necessary.

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