Re: grub-dumpbios
On Tue, May 5, 2009 at 3:45 PM, Bean bean12...@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) ___ 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 6f 6c 6f 72 20 4c 43 44 0a 20 20 20 00 d4 AAPL01,IODisplayMode length: 4 bytes: 00 10 00 80
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
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 4:36 PM, Peter Cros pxwp...@gmail.com 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
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
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 r...@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
___
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
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
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 5, 2009 at 4:39 AM, Robert Millan r...@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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
