flashrom

flashrom@flashrom.org

1 participants
9187 discussions

Trying to flash Bios on MS-6728
by Manuel Luitz 19 Aug '10

19 Aug '10

Hi guys, I just tried to flash the bios on my MSI board 865PE Neo2-PLS v1 (MS-6728) via flashrom. The chip recognition and reading works flawlessly and produced valid output. Writing to the ROM chip produces an error, listed in the attachment. I also attached the output of lspci, superiotool and flashrom -V. Hope you can play around with this data. Hope I will hear from you, Greets, Manuel

1 0

SB700 IMC disabling
by Carl-Daniel Hailfinger 19 Aug '10

19 Aug '10

Hi Zheng, running flashrom on certain systems with SB700 family chipsets will result in read and write corruption. I have added a corruption check to latest flashrom, and it seems that the IMC will access flash even if flashrom holds the BiosSemaphore (LPC bridge config space register 0x40, bit 5). Matthias Kretz owns a Supermicro H8DGT with this problem, but other boards (including a MITAC development board) exhibit the same issue. If we use flashrom to write, the SPI registers (especially FIFO counter and FIFO) will lock up after some time, and we have not been successful in getting the stuck board working again. Is there a way to stop the IMC from the host or to stop all IMC flash accesses (including read and instruction fetch)? Regards, Carl-Daniel -- http://www.hailfinger.org/

2 2

flashrom -V for GA-E7AUM-DS2H
by Beelzebubbie 19 Aug '10

19 Aug '10

Здравствуйте, Flashrom. -- С уважением, Beelzebubbie mailto:Beelzebubbie@mail.ru

1 0

Re: [flashrom] Urgent: Flash part would be destroied by flashrom 0.9.2 once manager application is running.
by Hony.Chiang＠mic.com.tw 19 Aug '10

19 Aug '10

Hi Daniel, I follow your suggestion capture error messages from flashrom v0.9.2-runknown. We have probed SPI bus while that application is running, and have found that ROM shadow address 0xFFC00000 seems to be accessed. It may be the cause. Whatever, I have submitted the request of application modification to 3rd party, and expect that flashrom will be also improved in the future. Could you not post our messages from mail to Patchwork Flashrom web site for commerce? I appreciate for your immediate assistance here. Best Regards, Hony -----Original Message----- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006@gmx.net] Sent: Wednesday, August 18, 2010 11:42 PM To: hony.chiang (江昆仲 - MIC) Cc: victor.chen (陳文貴 - MIC); jerry.c (陳亭岳 - MIC); flashrom(a)flashrom.org Subject: Re: [flashrom] Urgent: Flash part would be destroied by flashrom 0.9.2 once manager application is running. Hi Hony, can you please update flashrom to the latest version from svn and then run flashrom -V -r test.rom while the 3rd party application is running? This should detect the corruption you were seeing. The corruption is no fixed yet, but detecting it is a good first step. Thanks! Regards, Carl-Daniel -- http://www.hailfinger.org/

1 0

Recall: Urgent: Flash part would be destroied by flashrom 0.9.2 once manager application is running.
by Hony.Chiang＠mic.com.tw 19 Aug '10

19 Aug '10

hony.chiang (江昆仲 - MIC) would like to recall the message, "[flashrom] Urgent: Flash part would be destroied by flashrom 0.9.2 once manager application is running.".

1 0

Re: [flashrom] Urgent: Flash part would be destroied by flashrom 0.9.2 once manager application is running.
by Hony.Chiang＠mic.com.tw 19 Aug '10

19 Aug '10

Hi Daniel, I follow your suggestion capture error messages from flashrom v0.9.2-runknown. We have probed SPI bus while that application is running, and have found that ROM shadow address 0xFFEC0000 seems to be accessed. It may be the cause. Whatever, I have submitted the request of application modification to 3rd party, and expect that flashrom will be also improved in the future. Could you not post our messages from mail to Patchwork Flashrom web site for commerce? I appreciate for your immediate assistance here. Best Regards, Hony -----Original Message----- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006@gmx.net] Sent: Wednesday, August 18, 2010 11:42 PM To: hony.chiang (江昆仲 - MIC) Cc: victor.chen (陳文貴 - MIC); jerry.c (陳亭岳 - MIC); flashrom(a)flashrom.org Subject: Re: [flashrom] Urgent: Flash part would be destroied by flashrom 0.9.2 once manager application is running. Hi Hony, can you please update flashrom to the latest version from svn and then run flashrom -V -r test.rom while the 3rd party application is running? This should detect the corruption you were seeing. The corruption is no fixed yet, but detecting it is a good first step. Thanks! Regards, Carl-Daniel -- http://www.hailfinger.org/

1 0

Re: [flashrom] [PATCH] Board enable for ASUS P5LP-LE
by Leon Zhang 18 Aug '10

18 Aug '10

lspci/superiotool: http://www.coreboot.org/pipermail/flashrom/2010-August/004495.html Signed-off-by: Michael Karcher <flashrom at mkarcher.dialup.fu-berlin.de <http://www.flashrom.org/mailman/listinfo/flashrom>> Tested-by: Leon Zhang <leoncamel(a)gmail.com> --- board_enable.c | 2 ++ print.c | 1 + 2 files changed, 3 insertions(+), 0 deletions(-) diff --git a/board_enable.c b/board_enable.c index ae0fbfa..dd56477 100644 --- a/board_enable.c +++ b/board_enable.c @@ -1309,6 +1309,7 @@ static int intel_ich_gpio18_raise(void) /* * Suited for: * - ASUS A8Jm (laptop): Intel 945 + ICH7 + * - ASUS P5LP-LE (Epson/HP OEM) */ static int intel_ich_gpio34_raise(void) { @@ -1788,6 +1789,7 @@ const struct board_pciid_enable board_pciid_enables[] = { {0x1039, 0x0661, 0x1043, 0x8113, 0x1039, 0x5513, 0x1043, 0x8087, NULL, NULL, NULL, "ASUS", "P4S800-MX", 512, OK, w836xx_memw_enable_2e}, {0x10B9, 0x1541, 0, 0, 0x10B9, 0x1533, 0, 0, "^P5A$", "asus", "p5a", "ASUS", "P5A", 0, OK, board_asus_p5a}, {0x10DE, 0x0030, 0x1043, 0x818a, 0x8086, 0x100E, 0x1043, 0x80EE, NULL, NULL, NULL, "ASUS", "P5ND2-SLI Deluxe", 0, OK, nvidia_mcp_gpio10_raise}, + {0x8086, 0x27b8, 0x1043, 0x2a22, 0x8086, 0x2770, 0x1043, 0x2a22, NULL, NULL, NULL, "ASUS", "P5LP-LE", 0, OK, intel_ich_gpio34_raise}, {0x8086, 0x24dd, 0x1043, 0x80a6, 0x8086, 0x2570, 0x1043, 0x8157, NULL, NULL, NULL, "ASUS", "P5PE-VM", 0, OK, intel_ich_gpio21_raise}, {0x8086, 0x3590, 0x1028, 0x016c, 0x1000, 0x0030, 0x1028, 0x016c, NULL, NULL, NULL, "Dell", "PowerEdge 1850", 0, OK, intel_ich_gpio23_raise}, {0x1106, 0x3038, 0x1019, 0x0996, 0x1106, 0x3177, 0x1019, 0x0996, NULL, NULL, NULL, "Elitegroup", "K7VTA3", 256, OK, NULL}, diff --git a/print.c b/print.c index 4871cc8..933ac2c 100644 --- a/print.c +++ b/print.c @@ -366,6 +366,7 @@ const struct board_info boards_known[] = { B("ASUS", "P5KC", 1, "http://www.asus.com/product.aspx?P_ID=fFZ8oUIGmLpwNMjj", NULL), B("ASUS", "P5L-MX", 1, "http://www.asus.com/product.aspx?P_ID=X70d3NCzH2DE9vWH", NULL), B("ASUS", "P5ND2-SLI Deluxe", 1, "http://www.asus.com/product.aspx?P_ID=WY7XroDuUImVbgp5", NULL), + B("ASUS", "P5LP-LE", 1, NULL, NULL), /* OEM board, no ASUS URL */ B("ASUS", "P5PE-VM", 1, "http://www.asus.com/product.aspx?P_ID=k3h0ZFVu9Lo1dUvk", NULL), B("ASUS", "P6T SE", 1, "http://www.asus.com/product.aspx?P_ID=t4yhK6y9W9o7iQ9E", NULL), B("ASUS", "P6T Deluxe", 1, "http://www.asus.com/product.aspx?P_ID=vXixf82co6Q5v0BZ", NULL),

1 0

ASUS P5LP-LE
by Leon Zhang 18 Aug '10

18 Aug '10

http://faq.epsondirect.co.jp/faq/dl/app/servlet/relatedqa?QID=010372 Model: MT7700

2 1

[PATCH] SB700 IMC arbitration
by Carl-Daniel Hailfinger 18 Aug '10

18 Aug '10

Try to request the BIOS semaphore on SB700 family southbridges. This is a really gross hack and should _not_ enter the tree as is. It is also potentially dangerous on SB600, and will slow down all flash accesses a lot. It is a really simple patch designed to test my assumptions about locking. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-sb700_spi_imc_flash_arbitration/sb600spi.c =================================================================== --- flashrom-sb700_spi_imc_flash_arbitration/sb600spi.c (Revision 1145) +++ flashrom-sb700_spi_imc_flash_arbitration/sb600spi.c (Arbeitskopie) @@ -42,6 +42,7 @@ */ static uint8_t *sb600_spibar = NULL; +static struct pci_dev *lpc_bridge = NULL; int sb600_spi_read(struct flashchip *flash, uint8_t *buf, int start, int len) { @@ -100,6 +101,71 @@ ; } +static int request_flash_access(void) +{ + uint8_t tmp; + int i = 0; + + tmp = pci_read_byte(lpc_bridge, 0x40); + if (tmp & (1 << 6)) { + msg_pspew("Waiting for SB600 IMC to release flash access.\n"); + while (pci_read_byte(lpc_bridge, 0x40) & (1 << 6)) { + if (++i > 1024) { + msg_perr("SB600 IMC did not release flash.\n"); + return 1; + } + } + msg_pspew("SB600 IMC released flash access after %i cycles.\n", + i); + i = 0; + } + + if (tmp & (1 << 5)) { + /* Is this an error? */ + msg_pdbg("Strange. SB600 flash access requested although it " + "was already granted.\n"); + return 0; + } + + /* Request BiosSemaphore. */ + tmp = pci_read_byte(lpc_bridge, 0x40); + tmp |= 1 << 5; + pci_write_byte(lpc_bridge, 0x40, tmp); + while (!(pci_read_byte(lpc_bridge, 0x40) & (1 << 5))) { + if (++i > 1024) { + msg_perr("SB600 flash access was not granted.\n"); + return 1; + } + } + tmp = pci_read_byte(lpc_bridge, 0x40); + if (tmp & (1 << 6)) { + msg_perr("Very strange. SB600 IMC has flash access although " + "we requested SB600 flash access.\n"); + return 1; + } + msg_pspew("SB600 flash access granted after %i cycles.\n", i); + return 0; +} + +static int release_flash_access(void) +{ + uint8_t tmp; + + tmp = pci_read_byte(lpc_bridge, 0x40); + if (tmp & (1 << 6)) { + /* Is this an error? */ + msg_pdbg("Strange. SB600 IMC already has flash access.\n"); + } + if (!(tmp & (1 << 5))) { + /* Is this an error? */ + msg_pdbg("Strange. SB600 already released flash access.\n"); + } + tmp &= ~(1 << 5); + pci_write_byte(lpc_bridge, 0x40, tmp); + + return 0; +} + int sb600_spi_send_command(unsigned int writecnt, unsigned int readcnt, const unsigned char *writearr, unsigned char *readarr) { @@ -126,6 +192,13 @@ return SPI_INVALID_LENGTH; } + /* FIXME: Waiting for arbitration here is stupid. We need arbitration + * either at the start of a multicommand, or even at SB600 init. + * FIXME: Check if arbitration also is needed on SB600. + */ + if (request_flash_access()) + return SPI_PROGRAMMER_ERROR; + /* This is a workaround for a bug in SB600 and SB700. If we only send * an opcode and no additional data/address, the SPI controller will * read one byte too few from the chip. Basically, the last byte of @@ -199,6 +272,7 @@ "flash chip.\n"); return SPI_PROGRAMMER_ERROR; } + release_flash_access(); return 0; } @@ -212,6 +286,8 @@ "Reserved", "33", "22", "16.5" }; + lpc_bridge = dev; + /* Read SPI_BaseAddr */ tmp = pci_read_long(dev, 0xa0); tmp &= 0xffffffe0; /* remove bits 4-0 (reserved) */ -- http://www.hailfinger.org/

1 0

Urgent: Flash part would be destroied by flashrom 0.9.2 once manager application is running.
by Hony.Chiang＠mic.com.tw 18 Aug '10

18 Aug '10

Hi Sirs, Nice to have your support. I get the serious problem on flashrom 0.9.2 on our server systems. We always have to run 3rd party manager application to call up flashrom for BIOS upgrade. However, flashrom would be failed on “Verifying flash” step because some of programmed data in flash part is different with ones in golden ROM image file on random offset addresses. This defect occurs on Red Hat 5 x64, SLES 10 x64 and SLES 11 x64. If I run flashrom tool manually without this 3rd application, it would always flash SPI part successfully. Due to the 3rd party application is confidential, it can not be provided to you for defect reproduction. Q1: May I suspect that expected data that is written to mapped virtual memory space by flashrom is overwritten or interfered by other process from 3rd application before SPI host controller operates these data to SPI ROM? Q2: May I suspect that expected data that is written to mapped virtual memory space by flashrom is not sync to physical memory space immediately when SPI host controller operates these data to SPI ROM? Q3: In order to prevent other process to interfere /dev/mem, mapped virtual memory space or physical memory space that flashrom uses, would you have any idea or some slice codes to lock them during flashrom operation? Q4: Would you have any idea to trace the root cause interfered flashrom? Please advise me your professional comments. Thanks!! Verbose message: Programming flash done. COMPLETE. Verifying flash... VERIFY FAILED at 0x00017ca4! Expected=0xff, Read=0x25, failed byte count from 0x00000000-0x003fffff: 0x3a Your flash chip is in an unknown state. Get help on IRC at irc.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org! ------------------------------------------------------------------------------- DO NOT REBOOT OR POWEROFF! Syntax: ./flashrom –w 24a.rom Hardware configuration: MB: AMD platform solution South Bridge: AMD SP5100 Flash part: ST M25P32 NOS: Reg Hat 5 X86_X64 SLES 10 X86_X64 SLES 11 X86_X64 Best Regards, Hony Chiang

3 16

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom