* grub-dumpbios
@ 2009-05-04 19:27 Robert Millan
2009-05-04 19:57 ` grub-dumpbios Bean
2009-05-04 20:28 ` grub-dumpbios Stefan Reinauer
0 siblings, 2 replies; 12+ messages in thread
From: Robert Millan @ 2009-05-04 19:27 UTC (permalink / raw)
To: grub-devel
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."
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: grub-dumpbios 2009-05-04 19:27 grub-dumpbios Robert Millan @ 2009-05-04 19:57 ` Bean 2009-05-04 20:39 ` grub-dumpbios Robert Millan 2009-05-04 20:28 ` grub-dumpbios Stefan Reinauer 1 sibling, 1 reply; 12+ messages in thread From: Bean @ 2009-05-04 19:57 UTC (permalink / raw) To: The development of GRUB 2 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: grub-dumpbios 2009-05-04 19:57 ` grub-dumpbios Bean @ 2009-05-04 20:39 ` Robert Millan 2009-05-05 0:54 ` grub-dumpbios step21 2009-05-05 5:45 ` grub-dumpbios Bean 0 siblings, 2 replies; 12+ messages in thread From: Robert Millan @ 2009-05-04 20:39 UTC (permalink / raw) To: The development of GRUB 2 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." ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: grub-dumpbios 2009-05-04 20:39 ` grub-dumpbios Robert Millan @ 2009-05-05 0:54 ` step21 2009-05-05 5:45 ` grub-dumpbios Bean 1 sibling, 0 replies; 12+ messages in thread From: step21 @ 2009-05-05 0:54 UTC (permalink / raw) To: The development of GRUB 2 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: grub-dumpbios 2009-05-04 20:39 ` grub-dumpbios Robert Millan 2009-05-05 0:54 ` grub-dumpbios step21 @ 2009-05-05 5:45 ` Bean 2009-05-05 6:38 ` grub-dumpbios Peter Cros ` (2 more replies) 1 sibling, 3 replies; 12+ messages in thread From: Bean @ 2009-05-05 5:45 UTC (permalink / raw) To: The development of GRUB 2 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: grub-dumpbios 2009-05-05 5:45 ` grub-dumpbios Bean @ 2009-05-05 6:38 ` Peter Cros 2009-05-05 12:23 ` grub-dumpbios Vladimir 'phcoder' Serbinenko 2009-10-14 18:23 ` grub-dumpbios Robert Millan 2 siblings, 0 replies; 12+ messages in thread From: Peter Cros @ 2009-05-05 6:38 UTC (permalink / raw) To: The development of GRUB 2 [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: grub-dumpbios 2009-05-05 5:45 ` grub-dumpbios Bean 2009-05-05 6:38 ` grub-dumpbios Peter Cros @ 2009-05-05 12:23 ` Vladimir 'phcoder' Serbinenko 2009-05-05 12:25 ` grub-dumpbios Vladimir 'phcoder' Serbinenko 2009-10-14 18:23 ` grub-dumpbios Robert Millan 2 siblings, 1 reply; 12+ messages in thread From: Vladimir 'phcoder' Serbinenko @ 2009-05-05 12:23 UTC (permalink / raw) To: The development of GRUB 2 [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: grub-dumpbios 2009-05-05 12:23 ` grub-dumpbios Vladimir 'phcoder' Serbinenko @ 2009-05-05 12:25 ` Vladimir 'phcoder' Serbinenko 2009-05-05 14:36 ` grub-dumpbios Peter Cros 0 siblings, 1 reply; 12+ messages in thread From: Vladimir 'phcoder' Serbinenko @ 2009-05-05 12:25 UTC (permalink / raw) To: The development of GRUB 2 [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: grub-dumpbios 2009-05-05 12:25 ` grub-dumpbios Vladimir 'phcoder' Serbinenko @ 2009-05-05 14:36 ` Peter Cros 2009-05-05 14:47 ` grub-dumpbios Vladimir 'phcoder' Serbinenko 0 siblings, 1 reply; 12+ messages in thread From: Peter Cros @ 2009-05-05 14:36 UTC (permalink / raw) To: The development of GRUB 2 [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: grub-dumpbios 2009-05-05 14:36 ` grub-dumpbios Peter Cros @ 2009-05-05 14:47 ` Vladimir 'phcoder' Serbinenko 0 siblings, 0 replies; 12+ messages in thread From: Vladimir 'phcoder' Serbinenko @ 2009-05-05 14:47 UTC (permalink / raw) To: The development of GRUB 2 [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: grub-dumpbios 2009-05-05 5:45 ` grub-dumpbios Bean 2009-05-05 6:38 ` grub-dumpbios Peter Cros 2009-05-05 12:23 ` grub-dumpbios Vladimir 'phcoder' Serbinenko @ 2009-10-14 18:23 ` Robert Millan 2 siblings, 0 replies; 12+ messages in thread From: Robert Millan @ 2009-10-14 18:23 UTC (permalink / raw) To: The development of GRUB 2 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." ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: grub-dumpbios 2009-05-04 19:27 grub-dumpbios Robert Millan 2009-05-04 19:57 ` grub-dumpbios Bean @ 2009-05-04 20:28 ` Stefan Reinauer 1 sibling, 0 replies; 12+ messages in thread From: Stefan Reinauer @ 2009-05-04 20:28 UTC (permalink / raw) To: The development of GRUB 2 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2009-10-14 18:23 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-05-04 19:27 grub-dumpbios Robert Millan 2009-05-04 19:57 ` grub-dumpbios Bean 2009-05-04 20:39 ` grub-dumpbios Robert Millan 2009-05-05 0:54 ` grub-dumpbios step21 2009-05-05 5:45 ` grub-dumpbios Bean 2009-05-05 6:38 ` grub-dumpbios Peter Cros 2009-05-05 12:23 ` grub-dumpbios Vladimir 'phcoder' Serbinenko 2009-05-05 12:25 ` grub-dumpbios Vladimir 'phcoder' Serbinenko 2009-05-05 14:36 ` grub-dumpbios Peter Cros 2009-05-05 14:47 ` grub-dumpbios Vladimir 'phcoder' Serbinenko 2009-10-14 18:23 ` grub-dumpbios Robert Millan 2009-05-04 20:28 ` grub-dumpbios Stefan Reinauer
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.