flashrom

flashrom@flashrom.org

5 participants
9161 discussions

Patch: Support ASUS M2NBP-VM CSM
by Michael Karcher 07 Mar '10

07 Mar '10

Add board enable for Asus M2NBP-VM CSM Signed-Off-By: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> Index: board_enable.c =================================================================== --- board_enable.c (Revision 803) +++ board_enable.c (Arbeitskopie) @@ -450,6 +450,7 @@ case 0x0030: /* CK804 */ case 0x0050: /* MCP04 */ case 0x0060: /* MCP2 */ + case 0x0264: /* MCP51 */ break; default: fprintf(stderr, "\nERROR: no nVidia SMBus controller found.\n"); @@ -470,6 +471,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 ASUS P5ND2-SLI Deluxe: LGA775 + nForce4 SLI + MCP04. */ static int nvidia_mcp_gpio10_raise(const char *name) @@ -1226,6 +1235,7 @@ {0x1106, 0x3189, 0x1043, 0x807F, 0x1106, 0x3177, 0x1043, 0x808C, NULL, NULL, "ASUS", "A7V8X", board_asus_a7v8x}, {0x1106, 0x3177, 0x1043, 0x80A1, 0x1106, 0x3205, 0x1043, 0x8118, NULL, NULL, "ASUS", "A7V8X-MX SE", board_asus_a7v8x_mx}, {0x1106, 0x1336, 0x1043, 0x80ed, 0x1106, 0x3288, 0x1043, 0x8249, NULL, NULL, "ASUS", "M2V-MX", board_asus_m2v_mx}, + {0x10DE, 0x0264, 0x1043, 0x81C0, 0x10DE, 0x0260, 0x1043, 0x81C0, NULL, NULL, "ASUS", "M2NBP-VM CSM", nvidia_mcp_gpio0_raise}, {0x8086, 0x1a30, 0x1043, 0x8070, 0x8086, 0x244b, 0x1043, 0x8028, NULL, NULL, "ASUS", "P4B266", intel_ich_gpio22_raise}, {0x8086, 0x1A30, 0x1043, 0x8025, 0x8086, 0x244B, 0x104D, 0x80F0, NULL, NULL, "ASUS", "P4B266-LM", intel_ich_gpio21_raise}, {0x8086, 0x2570, 0x1043, 0x80F2, 0x105A, 0x3373, 0x1043, 0x80F5, NULL, NULL, "ASUS", "P4P800-E Deluxe", intel_ich_gpio21_raise},

3 3

Re: [flashrom] [PATCH] Board enable for HP Vectra VL420SFF
by Carl-Daniel Hailfinger 07 Mar '10

07 Mar '10

On 12.02.2010 17:09, Michael Karcher wrote: > 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. > > Signed-off-by: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> > --- > Hello Mattias, could you please try whether current svn flashrom (at least > r896) with this patch applied outputs > Disabling write protection for HP VL420 SFF > on invocation with "flashrom -V"? If yes, please reply to this mail with a > mail containing the line "Acked-by: Mattias Mattsson <vitplister(a)gmail.com>". > You don't have to try anything dangerous like erasing/writing the flash > chip, as only the board recognition has changed. > This was committed in r923. Regards, Carl-Daniel -- "I do consider assignment statements and pointer variables to be among computer science's most valuable treasures." -- Donald E. Knuth

1 0

Re: [flashrom] [PATCH] Board enable for Abit IP35 Pro
by Tim L. 07 Mar '10

07 Mar '10

Acked-by: Timothy Lepre <K <your(a)email.address>lavious(a)gmail.com> On Tue, Mar 2, 2010 at 7:12 PM, Michael Karcher < flashrom(a)mkarcher.dialup.fu-berlin.de> wrote: > This board is like the IP35. Just changed the IDs to match. > > Signed-off-by: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> > --- > board_enable.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/board_enable.c b/board_enable.c > index a479924..d28490c 100644 > --- a/board_enable.c > +++ b/board_enable.c > @@ -891,6 +891,7 @@ static int intel_ich_gpio_set(int gpio, int raise) > > /** > * Suited for Abit IP35: Intel P35 + ICH9R. > + * Suited for Abit IP35 Pro: Intel P35 + ICH9R. > */ > static int intel_ich_gpio16_raise(const char *name) > { > @@ -1253,6 +1254,7 @@ struct board_pciid_enable board_pciid_enables[] = { > > /* first pci-id set [4], second pci-id set [4], > dmi identifier coreboot id [2], vendor name board name > max_rom_... OK? flash enable */ > {0x8086, 0x2926, 0x147b, 0x1084, 0x11ab, 0x4364, 0x147b, 0x1084, > NULL, NULL, NULL, "Abit", "IP35", > 0, OK, intel_ich_gpio16_raise}, > + {0x8086, 0x2930, 0x147b, 0x1083, 0x10ec, 0x8167, 0x147b, 0x1083, > NULL, NULL, NULL, "Abit", "IP35 Pro", > 0, OK, intel_ich_gpio16_raise}, > {0x105a, 0x0d30, 0x105a, 0x4d33, 0x8086, 0x1130, 0x8086, 0, > NULL, NULL, NULL, "Acorp", "6A815EPD", > 0, OK, board_acorp_6a815epd}, > {0x8086, 0x24D4, 0x1849, 0x24D0, 0x8086, 0x24D5, 0x1849, 0x9739, > NULL, NULL, NULL, "ASRock", "P4i65GV", > 0, OK, intel_ich_gpio23_raise}, > {0x1022, 0x746B, 0, 0, 0, 0, 0, 0, > NULL, "AGAMI", "ARUMA", "agami", "Aruma", > 0, OK, w83627hf_gpio24_raise_2e}, > -- > 1.7.0 > > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom > >

2 1

Failed BIOS Flash Assistance
by bas nowaira 07 Mar '10

07 Mar '10

Greetings, Per my conversation with agaran on irc, please find the attached log of: < agaran> !summary bassem < flashrom_bot> bassem: please mail the output of 'flashrom -V', 'lspci -nnvvvxxx', 'superiotool -deV' (all commands as root), the exact name of your board (including revision, if there are multiple revisions), and a link to the official BIOS download to flashrom(a)flashrom.org I appreciate all the assistance you can provide. -- /* bas */

4 8

[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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom