flashrom March 2010

flashrom@flashrom.org

49 participants
211 discussions

[Patch] Board enable for Asus P4B266-LM
by Luc Verhaegen 07 Mar '10

07 Mar '10

This is a resend of the previous patch, now using the intel_ich_gpio_raise function. I have now created a separate function, instead of hooking this code onto another board enable that also raises gpio21 (but with a different ICH). Allan, i know you have given an Ack already, but this is now based on more general infrastructure. Can you give this patch a whirl too? You will have to apply this patch here first though: http://patchwork.coreboot.org/patch/467/raw/ Thanks, Luc Verhaegen.

2 1

Re: [flashrom] [PATCH] Move ntested board enable documentation to manpage
by Carl-Daniel Hailfinger 07 Mar '10

07 Mar '10

Hi Michael, On 07.03.2010 17:24, Michael Karcher wrote: > This also checks the testedness of boards in all cases, not just for > PCI/DMI detection. > > Signed-off-by: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> > Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> > Hello Carl-Daniel, > > This should address all the issues you raised in your review. > Thanks! One minor comment, otherwise it looks OK. No need to repost, just commit the updated version. > Regards, > Michael Karcher > > diff --git a/board_enable.c b/board_enable.c > index d28490c..7381940 100644 > --- a/board_enable.c > +++ b/board_enable.c > @@ -1411,30 +1411,6 @@ static struct board_pciid_enable *board_match_pci_card_ids(void) > } > } > > - if (board->status == NT) { > - if (!force_boardenable) > - { > - printf("WARNING: Your mainboard is %s %s, but the mainboard-specific\n" > - "code has not been marked as working. To help flashrom development, please\n" > - "test flashrom on your board. As the code to support your board is untested,\n" > - "we strongly recommend that as an additional safety measure you make\n" > - "store backup of your current ROM contents (obtained by flashrom -r) on\n" > - "a medium that can be accessed from a different computer (like an USB\n" > - "drive or a network share of another system) before you try to erase or\n" > - "write.\n" > - "The untested code does not run unless you specify the\n" > - " \"-p internal:boardenable=force\" command line option. Depending on your\n" > - "hardware environment, erasing, writing or even probing can fail without\n" > - "running the board specific code. Running the board-specific code might\n" > - "cause your computer to behave erratically if it is wrong.\n" > - "Please report the results of running the board enable code to\n" > - "flashrom(a)flashrom.org.\n", > - board->vendor_name, board->board_name); > - continue; > - } > - printf("NOTE: Running an untested board enable procedure.\n" > - "Please report success/failure to flashrom(a)flashrom.org\n"); > - } > return board; > } > > @@ -1452,6 +1428,23 @@ int board_flash_enable(const char *vendor, const char *part) > if (!board) > board = board_match_pci_card_ids(); > > + if (board->status == NT) { > + if (!force_boardenable) > + { > + printf("WARNING: Your mainboard is %s %s, but the mainboard-specific\n" > + "code has not been tested, and thus will not not be executed by default.\n" > + "Depending on your hardware environment, erasing, writing or even probing\n" > + "can fail without running the board specific code.\n\n" > + "Please see the man page (section PROGRAMMER SPECIFIC INFO, subsection\n" > + "\"internal programmer\" for details\n", > + board->vendor_name, board->board_name); > + board = NULL; > + } > + else > + printf("NOTE: Running an untested board enable procedure.\n" > + "Please report success/failure to flashrom(a)flashrom.org\n"); > + } > + > if (board) { > if (board->max_rom_decode_parallel) > max_rom_decode.parallel = > diff --git a/flashrom.8 b/flashrom.8 > index 696aba2..46dca21 100644 > --- a/flashrom.8 > +++ b/flashrom.8 > @@ -175,6 +175,46 @@ colon. While some programmers take arguments at fixed positions, other > programmers use a key/value interface in which the key and value is separated > by an equal sign and different pairs are separated by a comma or a colon. > .TP > +.BR "internal " programmer > +Some mainboards require to run mainboard specific code to enable erase and > ... to enable chip erase and ... > +write support (on old systems with parallel flash even probe support). The > ... (and probe support on old systems with parallel flash). > +type of the mainboard (if it requires specific code) is usually autodetected > The mainboard brand and model (.... > +using one of the following mechanisms: If your system is running coreboot, > +the mainboard type is determined from the coreboot table, otherwise, the > +mainboard is detected by examining the onboard PCI devices and possibly DMI > +info. If PCI and DMI do not contain information to uniquely identify the > +mainboard (which is the exception), it might be needed to specify the > ... might be necessary to specify ... > +mainboard using the \-m switch (see above). > +.sp > +Some of these board-specific flash enabling functions (called board enables) > +in flashrom have not yet been tested. If your mainboard is detected needing an untested > untested untested? [Kill one of them] > +untested board-enable function, a warning message is printed and the board > ... untested board enable ... [remove -] > +enable is not executed, because a wrong board enable function might cause the > +system to behave erratically, as board enable functions touch the low-level > +internals of a mainboard. This might cause detection or erasing > Not executing a board enable function (if one is needed) might cause ... > +failure. If your board protects only part of the flash (commonly the top > +end, called boot block), flashrom might encounter the error only after > ...encounter an error ... > +erasing the other part, so running without the board-enable function might > ...erasing the unprotected part... > +be dangerous for erase and write (which includes erase). > +.sp > +The suggested procedure for a mainboard with untested board specific code is > +to first try to probe the ROM (just invoke flashrom and check that it detects > +your flash chip type) without running the board enable code (i.e. without any > +parameters). If it finds your chip, fine, otherwise, retry probing your chip > +with the board-enable code running, using > +.sp > +.B "flashrom -p internal:boardenable=force" > +.sp > +If your chip is still not detected, the board enable code seems to be broken > +or the chip unsupported. Otherwise, make a backup of your current ROM > ... or the flash chip is unsupported. > +contents (using \-r) and store it to a medium outside of your computer, like > +an USB drive or a network share. If you needed to run the board enable code > +already for probing, use it for reading too. Now you can try to write the > +new image. You should enable the board enable code in any case now, as it > +has been written because it is known that writing/erasing without the board > +enable is going to fail. In any case (success or failure), please report > +to the flashrom mailing list, see below. > +.sp > .BR "dummy " programmer > An optional parameter specifies the bus types it > should support. For that you have to use the > Looks good otherwise. I'm not a native speaker, so I might have overlooked something. Still, your text is way better than what we have now, so go ahead. Regards, Carl-Daniel -- "I do consider assignment statements and pointer variables to be among computer science's most valuable treasures." -- Donald E. Knuth

2 1

flashrom P R E W successful for W49F002U12B on MSI MS6330 K7T Turbo VER:3
by Guy Lacroix 07 Mar '10

07 Mar '10

PLease find included the flashrom results. Model info and link to bios are in MS6330 W49F002U12B file.

1 0

[commit] r926 - trunk
by repository service 07 Mar '10

07 Mar '10

Author: mkarcher Date: Sun Mar 7 23:29:28 2010 New Revision: 926 URL: http://flashrom.org/trac/coreboot/changeset/926 Log: Move untested board enable documentation to manpage This also checks the testedness of boards in all cases, not just for PCI/DMI detection. Signed-off-by: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/board_enable.c trunk/flashrom.8 Modified: trunk/board_enable.c ============================================================================== --- trunk/board_enable.c Sun Mar 7 17:52:59 2010 (r925) +++ trunk/board_enable.c Sun Mar 7 23:29:28 2010 (r926) @@ -1425,30 +1425,6 @@ } } - if (board->status == NT) { - if (!force_boardenable) - { - printf("WARNING: Your mainboard is %s %s, but the mainboard-specific\n" - "code has not been marked as working. To help flashrom development, please\n" - "test flashrom on your board. As the code to support your board is untested,\n" - "we strongly recommend that as an additional safety measure you make\n" - "store backup of your current ROM contents (obtained by flashrom -r) on\n" - "a medium that can be accessed from a different computer (like an USB\n" - "drive or a network share of another system) before you try to erase or\n" - "write.\n" - "The untested code does not run unless you specify the\n" - " \"-p internal:boardenable=force\" command line option. Depending on your\n" - "hardware environment, erasing, writing or even probing can fail without\n" - "running the board specific code. Running the board-specific code might\n" - "cause your computer to behave erratically if it is wrong.\n" - "Please report the results of running the board enable code to\n" - "flashrom(a)flashrom.org.\n", - board->vendor_name, board->board_name); - continue; - } - printf("NOTE: Running an untested board enable procedure.\n" - "Please report success/failure to flashrom(a)flashrom.org\n"); - } return board; } @@ -1466,6 +1442,23 @@ if (!board) board = board_match_pci_card_ids(); + if (board->status == NT) { + if (!force_boardenable) + { + printf("WARNING: Your mainboard is %s %s, but the mainboard-specific\n" + "code has not been tested, and thus will not not be executed by default.\n" + "Depending on your hardware environment, erasing, writing or even probing\n" + "can fail without running the board specific code.\n\n" + "Please see the man page (section PROGRAMMER SPECIFIC INFO, subsection\n" + "\"internal programmer\") for details\n", + board->vendor_name, board->board_name); + board = NULL; + } + else + printf("NOTE: Running an untested board enable procedure.\n" + "Please report success/failure to flashrom(a)flashrom.org\n"); + } + if (board) { if (board->max_rom_decode_parallel) max_rom_decode.parallel = Modified: trunk/flashrom.8 ============================================================================== --- trunk/flashrom.8 Sun Mar 7 17:52:59 2010 (r925) +++ trunk/flashrom.8 Sun Mar 7 23:29:28 2010 (r926) @@ -175,6 +175,47 @@ programmers use a key/value interface in which the key and value is separated by an equal sign and different pairs are separated by a comma or a colon. .TP +.BR "internal " programmer +Some mainboards require to run mainboard specific code to enable flash erase +and write support (and probe support on old systems with parallel flash). +The mainboard brand and model (if it requires specific code) is usually +autodetected using one of the following mechanisms: If your system is +running coreboot, the mainboard type is determined from the coreboot table, +otherwise, the mainboard is detected by examining the onboard PCI devices +and possibly DMI info. If PCI and DMI do not contain information to uniquely +identify the mainboard (which is the exception), it might be necessary to +specify the mainboard using the \-m switch (see above). +.sp +Some of these board-specific flash enabling functions (called board enables) +in flashrom have not yet been tested. If your mainboard is detected needing +an untested board enable function, a warning message is printed and the +board enable is not executed, because a wrong board enable function might +cause the system to behave erratically, as board enable functions touch the +low-level internals of a mainboard. Not executing a board enable function +(if one is needed) might cause detection or erasing failure. If your board +protects only part of the flash (commonly the top end, called boot block), +flashrom might encounter an error only after erasing the unprotected part, +so running without the board-enable function might be dangerous for erase +and write (which includes erase). +.sp +The suggested procedure for a mainboard with untested board specific code is +to first try to probe the ROM (just invoke flashrom and check that it +detects your flash chip type) without running the board enable code (i.e. +without any parameters). If it finds your chip, fine, otherwise, retry +probing your chip with the board-enable code running, using +.sp +.B "flashrom -p internal:boardenable=force" +.sp +If your chip is still not detected, the board enable code seems to be broken +or the flash chip unsupported. Otherwise, make a backup of your current ROM +contents (using \-r) and store it to a medium outside of your computer, like +an USB drive or a network share. If you needed to run the board enable code +already for probing, use it for reading too. Now you can try to write the +new image. You should enable the board enable code in any case now, as it +has been written because it is known that writing/erasing without the board +enable is going to fail. In any case (success or failure), please report to +the flashrom mailing list, see below. +.sp .BR "dummy " programmer An optional parameter specifies the bus types it should support. For that you have to use the

1 0

Releasing 0.9.2?
by Carl-Daniel Hailfinger 07 Mar '10

07 Mar '10

Hi, given that the eraseblock conversion is complete, what do we want to merge before 0.9.2? Here's my personal merge list: High priority: - Laptop warning. - DMI restructure (needed for laptop warning). - Chip driver fixes in patchwork. Medium priority: - All unacked board support patches (do we want to mark those boards as untested?) - All chip driver patches. Low priority: - All other pending patchwork patches, unless they are rejected or have unaddressed review points. TODO list: High priority: - Check if the man page is up to date (mention all programmers, use correct format for parameters, ...) - Fix compilation on Idwer's machine the right way because it might be broken in other setups as well. - Write a high-level changelog similar to the 0.9.1 changelog (see wiki). Medium priority: - Provide a --test mode (destructive) - Always read the chip before writing, and only issue the scary error message if flash contents changed. How fast do we have to release to meet various distribution cutoffs? I'm especially thinking of Ubuntu which ships a semi-broken flashrom version right now AFAICS. If we have to release Right Now(tm), I am happy if we get the high priority stuff merged/implemented. Regards, Carl-Daniel -- "I do consider assignment statements and pointer variables to be among computer science's most valuable treasures." -- Donald E. Knuth

4 7

[commit] r925 - trunk
by repository service 07 Mar '10

07 Mar '10

Author: mkarcher Date: Sun Mar 7 17:52:59 2010 New Revision: 925 URL: http://flashrom.org/trac/coreboot/changeset/925 Log: Board enable for MS-7202 (K8N GM2-L) Board enable code is untested, marked as such. Signed-off-by: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> Acked-by: Sean Nelson <audiohacked(a)gmail.com> Modified: trunk/board_enable.c Modified: trunk/board_enable.c ============================================================================== --- trunk/board_enable.c Sun Mar 7 17:42:55 2010 (r924) +++ trunk/board_enable.c Sun Mar 7 17:52:59 2010 (r925) @@ -554,6 +554,7 @@ /** * Suited for MSI K8N Neo4: nVidia CK804. + * Suited for MSI K8N GM2-L: nVidia MCP51. */ static int nvidia_mcp_gpio2_raise(const char *name) { @@ -1312,6 +1313,7 @@ {0x1039, 0x7012, 0x1462, 0x0050, 0x1039, 0x6325, 0x1462, 0x0058, NULL, NULL, NULL, "MSI", "MS-7005 (651M-L)", 0, OK, board_msi_651ml}, {0x8086, 0x2658, 0x1462, 0x7046, 0x1106, 0x3044, 0x1462, 0x046d, NULL, NULL, NULL, "MSI", "MS-7046", 0, OK, intel_ich_gpio19_raise}, {0x10DE, 0x005E, 0x1462, 0x7135, 0x10DE, 0x0050, 0x1462, 0x7135, NULL, "msi", "k8n-neo3", "MSI", "MS-7135 (K8N Neo3)", 0, OK, w83627thf_gpio4_4_raise_4e}, + {0x10DE, 0x0270, 0x1462, 0x7207, 0x10DE, 0x0264, 0x1462, 0x7207, NULL, NULL, NULL, "MSI", "MS-7207 (K8N GM2-L)", 0, NT, nvidia_mcp_gpio2_raise}, {0x10DE, 0x005E, 0x1462, 0x7125, 0x10DE, 0x0052, 0x1462, 0x7125, NULL, NULL, NULL, "MSI", "K8N Neo4-F", 0, OK, nvidia_mcp_gpio2_raise}, {0x1106, 0x3099, 0, 0, 0x1106, 0x3074, 0, 0, NULL, "shuttle", "ak31", "Shuttle", "AK31", 0, OK, w836xx_memw_enable_2e}, {0x1106, 0x3104, 0x1297, 0xa238, 0x1106, 0x3059, 0x1297, 0xc063, NULL, NULL, NULL, "Shuttle", "AK38N", 256, OK, it8705f_write_enable_2e},

1 0

[commit] r924 - trunk
by repository service 07 Mar '10

07 Mar '10

Author: mkarcher Date: Sun Mar 7 17:42:55 2010 New Revision: 924 URL: http://flashrom.org/trac/coreboot/changeset/924 Log: Board enable for Asus M2NBP-VM CSM Board info: http://www.coreboot.org/pipermail/flashrom/2009-December/001373.html Signed-off-by: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> Acked-by: Sean Nelson <audiohacked(a)gmail.com> Modified: trunk/board_enable.c Modified: trunk/board_enable.c ============================================================================== --- trunk/board_enable.c Sun Mar 7 17:32:32 2010 (r923) +++ trunk/board_enable.c Sun Mar 7 17:42:55 2010 (r924) @@ -545,6 +545,14 @@ } /** + * Suited for ASUS M2NBP-VM CSM: nVidia MCP51. + */ +static int nvidia_mcp_gpio0_raise(const char *name) +{ + return nvidia_mcp_gpio_set(0x00, 1); +} + +/** * Suited for MSI K8N Neo4: nVidia CK804. */ static int nvidia_mcp_gpio2_raise(const char *name) @@ -1267,6 +1275,7 @@ {0x1106, 0x3189, 0x1043, 0x807F, 0x1106, 0x3065, 0x1043, 0x80ED, NULL, NULL, NULL, "ASUS", "A7V600-X", 0, OK, board_asus_a7v600x}, {0x1106, 0x3189, 0x1043, 0x807F, 0x1106, 0x3177, 0x1043, 0x808C, NULL, NULL, NULL, "ASUS", "A7V8X", 0, OK, board_asus_a7v8x}, {0x1106, 0x3177, 0x1043, 0x80A1, 0x1106, 0x3205, 0x1043, 0x8118, NULL, NULL, NULL, "ASUS", "A7V8X-MX SE", 0, OK, w836xx_memw_enable_2e}, + {0x10DE, 0x0264, 0x1043, 0x81C0, 0x10DE, 0x0260, 0x1043, 0x81C0, NULL, NULL, NULL, "ASUS", "M2NBP-VM CSM", 0, OK, nvidia_mcp_gpio0_raise}, {0x1106, 0x1336, 0x1043, 0x80ed, 0x1106, 0x3288, 0x1043, 0x8249, NULL, NULL, NULL, "ASUS", "M2V-MX", 0, OK, via_vt823x_gpio5_raise}, {0x8086, 0x1a30, 0x1043, 0x8070, 0x8086, 0x244b, 0x1043, 0x8028, NULL, NULL, NULL, "ASUS", "P4B266", 0, OK, intel_ich_gpio22_raise}, {0x8086, 0x1A30, 0x1043, 0x8025, 0x8086, 0x244B, 0x104D, 0x80F0, NULL, NULL, NULL, "ASUS", "P4B266-LM", 0, OK, intel_ich_gpio21_raise},

1 0

[commit] r923 - trunk
by repository service 07 Mar '10

07 Mar '10

Author: mkarcher Date: Sun Mar 7 17:32:32 2010 New Revision: 923 URL: http://flashrom.org/trac/coreboot/changeset/923 Log: Board enable for HP Vectra VL420SFF This code has been tested by Mattias Mattsson on 23. December 2009, but without the DMI match. Now that DMI support is in and working, the board can be added to mainline flashrom. board info: http://www.coreboot.org/pipermail/flashrom/2009-December/001440.html Signed-off-by: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> Acked-by: Sean Nelson <audiohacked(a)gmail.com> Modified: trunk/board_enable.c Modified: trunk/board_enable.c ============================================================================== --- trunk/board_enable.c Sun Mar 7 13:11:08 2010 (r922) +++ trunk/board_enable.c Sun Mar 7 17:32:32 2010 (r923) @@ -917,7 +917,9 @@ } /** - * Suited for ASUS P4B266: socket478 + intel 845D + ICH2. + * Suited for: + * - Asus P4B266: socket478 + intel 845D + ICH2. + * - Asus P4B-MX variant in HP Vectra VL420 SFF: socket478 + 845D + ICH2 */ static int intel_ich_gpio22_raise(const char *name) { @@ -1289,6 +1291,7 @@ {0x1002, 0x438d, 0x1458, 0x5001, 0x1002, 0x5956, 0x1002, 0x5956, NULL, NULL, NULL, "GIGABYTE", "GA-MA790FX-DQ6", 0, OK, it87xx_probe_spi_flash}, {0x1166, 0x0223, 0x103c, 0x320d, 0x102b, 0x0522, 0x103c, 0x31fa, NULL, "hp", "dl145_g3", "HP", "DL145 G3", 0, OK, board_hp_dl145_g3_enable}, {0x8086, 0x2415, 0x103c, 0x1249, 0x10b7, 0x9200, 0x103c, 0x1246, NULL, NULL, NULL, "HP", "Vectra VL400", 0, OK, board_hp_vl400}, + {0x8086, 0x1a30, 0x103c, 0x1a30, 0x8086, 0x2443, 0x103c, 0x2440, "^VL420$", NULL, NULL, "HP", "VL420 SFF", 0, OK, intel_ich_gpio22_raise}, {0x1166, 0x0205, 0x1014, 0x0347, 0x1002, 0x515E, 0x1014, 0x0325, NULL, NULL, NULL, "IBM", "x3455", 0, OK, board_ibm_x3455}, {0x1039, 0x5513, 0x8086, 0xd61f, 0x1039, 0x6330, 0x8086, 0xd61f, NULL, NULL, NULL, "Intel", "D201GLY", 0, OK, wbsio_check_for_spi}, {0x1022, 0x7468, 0, 0, 0, 0, 0, 0, NULL, "iwill", "dk8_htx", "IWILL", "DK8-HTX", 0, OK, w83627hf_gpio24_raise_2e},

1 0

Re: [flashrom] [PATCH] Refactor man page
by Carl-Daniel Hailfinger 07 Mar '10

07 Mar '10

On 07.03.2010 12:50, Michael Karcher wrote: > This patch puts the description of the different programmers into a > separate section of the manpage [...] > > Signed-off-by: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> > Thanks for the patch. Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Regards, Carl-Daniel -- "I do consider assignment statements and pointer variables to be among computer science's most valuable treasures." -- Donald E. Knuth

2 1

[commit] r922 - trunk
by repository service 07 Mar '10

07 Mar '10

Author: mkarcher Date: Sun Mar 7 13:11:08 2010 New Revision: 922 URL: http://flashrom.org/trac/coreboot/changeset/922 Log: Refactor man page This patch puts the description of the different programmers into a separate section of the manpage instead of having them one after the other without visual structuring in the description of "-p". It is made as a preparation of a man-page patch that adds the background of board enables into flashrom.8 that would really blow up the OPTIONS section. The only differences in content are: - The parameter for serprog is mandatory, not optional - Default behaviour of it87spi (using BIOS-set I/O address) is mentioned. - Default speed of buspiratespi is mentioned. Signed-off-by: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/flashrom.8 Modified: trunk/flashrom.8 ============================================================================== --- trunk/flashrom.8 Fri Mar 5 09:44:11 2010 (r921) +++ trunk/flashrom.8 Sun Mar 7 13:11:08 2010 (r922) @@ -131,7 +131,7 @@ but outputs the supported hardware in MediaWiki syntax, so that it can be easily pasted into the wiki page at http://www.flashrom.org/. .TP -.B "\-p, \-\-programmer <name>" +.B "\-p, \-\-programmer <name>[:parameters]" Specify the programmer device. Currently supported are: .sp .BR "* internal" " (default, for in-system flashing in the mainboard)" @@ -156,7 +156,27 @@ .sp .BR "* buspiratespi" " (for flash ROMs attached to a Bus Pirate)" .sp -The dummy programmer has an optional parameter specifying the bus types it +Some programmers have optional or mandatory parameters which are described +in detail in the +.B PROGRAMMER SPECIFIC INFO +section. Support for some programmers can be disabled at compile time. +.B "flashrom -h" +lists all supported programmers. +.TP +.B "\-h, \-\-help" +Show a help text and exit. +.TP +.B "\-R, \-\-version" +Show version information and exit. +.SH PROGRAMMER SPECIFIC INFO +Some programmer drivers accept further parameters to set programmer-specific +parameters. These parameters are seperated from the programmer name by a +colon. While some programmers take arguments at fixed positions, other +programmers use a key/value interface in which the key and value is separated +by an equal sign and different pairs are separated by a comma or a colon. +.TP +.BR "dummy " programmer +An optional parameter specifies the bus types it should support. For that you have to use the .B "flashrom -p dummy:type" syntax where @@ -167,11 +187,13 @@ .sp Example: .B "flashrom -p dummy:lpc,fwh" -.sp -If you have multiple supported PCI cards which can program flash chips -(NICs, SATA/IDE controllers, etc.) in your system, you must use the +.TP +.BR "nic3com" , " gfxnvidia" , " satasii" and " atahpt " programmers +These programmers have an option to specify the PCI address of the card +your want to use, which must be specified if more than one card supported +by the selected programmer is installed in your system. The syntax is .B "flashrom -p xxxx:bb:dd.f" -syntax to explicitly select one of them, where +, where .B xxxx is the name of the programmer .B bb @@ -183,22 +205,18 @@ .sp Example: .B "flashrom -p nic3com:05:04.0" -.sp -Currently the following programmers support this mechanism: -.BR nic3com , -.BR gfxnvidia , -.BR satasii , -.BR atahpt . -.sp -The it87spi programmer has an optional parameter which will set the I/O base -port of the IT87* SPI controller interface to the port specified in the -parameter. For that you have to use the +.TP +.BR "it87spi " programmer +An optional parameter sets the I/O base port of the IT87* SPI controller +interface to the port specified in the parameter instead of using the port +address set by the BIOS. For that you have to use the .B "flashrom -p it87spi:port=portnum" syntax where .B portnum is an I/O port number which must be a multiple of 8. -.sp -The ft2232spi programmer has an optional parameter specifying the controller +.TP +.BR "ft2232spi " programmer +An optional parameter species the controller type and interface/port it should support. For that you have to use the .B "flashrom -p ft2232spi:model,port=interface" syntax where @@ -208,41 +226,35 @@ and .B interface can be any of -.B A -.BR B . +.BR "A B" . The default model is .B 4232H and the default interface is .BR B . -.sp -The serprog programmer has an optional parameter specifying either a serial +.TP +.BR "serprog " programmer +A mandatory parameter specifies either a serial device/baud combination or an IP/port combination for communication with the -programmer. For serial, you have to use the +programmer. In the device/baud combination, the device has to start with a +slash. For serial, you have to use the .B "flashrom -p serprog:/dev/device:baud" syntax and for IP, you have to use .B "flashrom -p serprog:ip:port" instead. More information about serprog is available in serprog-protocol.txt in the source distribution. +.TP +.BR "buspiratespi " programmer +A required dev parameter specifyies the Bus Pirate device node and an optional +spispeed parameter specifyies the frequency of the SPI bus. The parameter +delimiter is a comma. Syntax is .sp -The buspiratespi programmer has a required dev parameter specifying the Bus -Pirate device node and an optional spispeed parameter specifying the frequency -of the SPI bus. The parameter delimiter is a comma. Syntax is .B "flashrom -p buspiratespi:dev=/dev/device,spispeed=frequency" +.sp where .B frequency can be any of .B 30k 125k 250k 1M 2M 2.6M 4M 8M -(in Hz). -.sp -Support for some programmers can be disabled at compile time. -.B "flashrom -h" -lists all supported programmers. -.TP -.B "\-h, \-\-help" -Show a help text and exit. -.TP -.B "\-R, \-\-version" -Show version information and exit. +(in Hz). The default is the maximum frequency of 8 MHz. .SH EXIT STATUS flashrom exits with 0 on success, 1 on most failures but with 2 if /dev/mem (/dev/xsvc on Solaris) can not be opened and with 3 if a call to mmap() fails.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom March 2010