Re: grub-dumpbios
On Tue, May 05, 2009 at 01:45:31PM +0800, Bean wrote: > On Tue, May 5, 2009 at 4:39 AM, Robert Millan 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." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-dumpbios
On Tue, May 5, 2009 at 4:36 PM, Peter Cros wrote: > > > On Tue, May 5, 2009 at 10:25 PM, Vladimir 'phcoder' Serbinenko < > phco...@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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-dumpbios
On Tue, May 5, 2009 at 10:25 PM, Vladimir 'phcoder' Serbinenko < phco...@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) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-dumpbios
On Tue, May 5, 2009 at 2:23 PM, Vladimir 'phcoder' Serbinenko < phco...@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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-dumpbios
> ... 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
Re: grub-dumpbios
On Tue, May 5, 2009 at 3:45 PM, Bean 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) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-dumpbios
On Tue, May 5, 2009 at 4:39 AM, Robert Millan 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-dumpbios
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 > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-dumpbios
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." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-dumpbios
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: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-dumpbios
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 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
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
grub-dumpbios
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
