flashrom August 2010

flashrom@flashrom.org

77 participants
209 discussions

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

[commit] r1145 - trunk
by repository service 18 Aug '10

18 Aug '10

Author: hailfinger Date: Wed Aug 18 17:12:43 2010 New Revision: 1145 URL: http://flashrom.org/trac/coreboot/changeset/1145 Log: Add paranoid checks for correct values in essential registers in the SB600/SB700/... SPI driver. If something else changes the values we wrote, we will see severe read/write corruption. sb600spi will now abort the access and return an error if it detects this sort of corruption. Note: This corruption can be caused by a few different events: - IPMI/BMC/IMC accesses flash - Other software accesses flash The nature of flash access (read/write/ID/...) is irrelevant. Each such access will cause corruption for all other accesses happening at the same time. Thanks to Matthias Kretz for testing this patch. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Matthias Kretz <kretz(a)kde.org> Modified: trunk/sb600spi.c trunk/spi.h Modified: trunk/sb600spi.c ============================================================================== --- trunk/sb600spi.c Tue Aug 17 00:12:39 2010 (r1144) +++ trunk/sb600spi.c Wed Aug 18 17:12:43 2010 (r1145) @@ -58,10 +58,40 @@ { mmio_writeb(mmio_readb(sb600_spibar + 2) | 0x10, sb600_spibar + 2); + /* FIXME: This loop makes no sense at all. */ while (mmio_readb(sb600_spibar + 0xD) & 0x7) msg_pspew("reset\n"); } +static int compare_internal_fifo_pointer(uint8_t want) +{ + uint8_t tmp; + + tmp = mmio_readb(sb600_spibar + 0xd) & 0x07; + want &= 0x7; + if (want != tmp) { + msg_perr("SB600 FIFO pointer corruption! Pointer is %d, wanted " + "%d\n", tmp, want); + msg_perr("Something else is accessing the flash chip and " + "causes random corruption.\nPlease stop all " + "applications and drivers and IPMI which access the " + "flash chip.\n"); + return 1; + } else { + msg_pspew("SB600 FIFO pointer is %d, wanted %d\n", tmp, want); + return 0; + } +} + +static int reset_compare_internal_fifo_pointer(uint8_t want) +{ + int ret; + + ret = compare_internal_fifo_pointer(want); + reset_internal_fifo_pointer(); + return ret; +} + static void execute_command(void) { mmio_writeb(mmio_readb(sb600_spibar + 2) | 1, sb600_spibar + 2); @@ -77,6 +107,7 @@ /* First byte is cmd which can not being sent through FIFO. */ unsigned char cmd = *writearr++; unsigned int readoffby1; + unsigned char readwrite; writecnt--; @@ -102,15 +133,17 @@ * It is unclear if the CS# line is set high too early as well. */ readoffby1 = (writecnt) ? 0 : 1; - mmio_writeb((readcnt + readoffby1) << 4 | (writecnt), sb600_spibar + 1); + readwrite = (readcnt + readoffby1) << 4 | (writecnt); + mmio_writeb(readwrite, sb600_spibar + 1); mmio_writeb(cmd, sb600_spibar + 0); /* Before we use the FIFO, reset it first. */ reset_internal_fifo_pointer(); /* Send the write byte to FIFO. */ + msg_pspew("Writing: "); for (count = 0; count < writecnt; count++, writearr++) { - msg_pspew(" [%x]", *writearr); + msg_pspew("[%02x]", *writearr); mmio_writeb(*writearr, sb600_spibar + 0xC); } msg_pspew("\n"); @@ -119,8 +152,10 @@ * We should send the data by sequence, which means we need to reset * the FIFO pointer to the first byte we want to send. */ - reset_internal_fifo_pointer(); + if (reset_compare_internal_fifo_pointer(writecnt)) + return SPI_PROGRAMMER_ERROR; + msg_pspew("Executing: \n"); execute_command(); /* @@ -134,21 +169,36 @@ * the opcode, the FIFO already stores the response from the chip. * Usually, the chip will respond with 0x00 or 0xff. */ - reset_internal_fifo_pointer(); + if (reset_compare_internal_fifo_pointer(writecnt + readcnt)) + return SPI_PROGRAMMER_ERROR; /* Skip the bytes we sent. */ + msg_pspew("Skipping: "); for (count = 0; count < writecnt; count++) { cmd = mmio_readb(sb600_spibar + 0xC); - msg_pspew("[ %2x]", cmd); + msg_pspew("[%02x]", cmd); } + msg_pspew("\n"); + if (compare_internal_fifo_pointer(writecnt)) + return SPI_PROGRAMMER_ERROR; - msg_pspew("The FIFO pointer after skipping is %d.\n", - mmio_readb(sb600_spibar + 0xd) & 0x07); + msg_pspew("Reading: "); for (count = 0; count < readcnt; count++, readarr++) { *readarr = mmio_readb(sb600_spibar + 0xC); msg_pspew("[%02x]", *readarr); } msg_pspew("\n"); + if (reset_compare_internal_fifo_pointer(readcnt + writecnt)) + return SPI_PROGRAMMER_ERROR; + + if (mmio_readb(sb600_spibar + 1) != readwrite) { + msg_perr("Unexpected change in SB600 read/write count!\n"); + msg_perr("Something else is accessing the flash chip and " + "causes random corruption.\nPlease stop all " + "applications and drivers and IPMI which access the " + "flash chip.\n"); + return SPI_PROGRAMMER_ERROR; + } return 0; } @@ -158,6 +208,10 @@ struct pci_dev *smbus_dev; uint32_t tmp; uint8_t reg; + const char *speed_names[4] = { + "Reserved", "33", "22", "16.5" + }; + /* Read SPI_BaseAddr */ tmp = pci_read_long(dev, 0xa0); tmp &= 0xffffffe0; /* remove bits 4-0 (reserved) */ @@ -183,15 +237,25 @@ msg_pdbg("PrefetchEnSPIFromIMC=%i, ", tmp); tmp = pci_read_byte(dev, 0xbb); + /* FIXME: Set bit 3,6,7 if not already set. + * Set bit 5, otherwise SPI accesses are pointless in LPC mode. + * See doc 42413 AMD SB700/710/750 RPR. + */ msg_pdbg("PrefetchEnSPIFromHost=%i, SpiOpEnInLpcMode=%i\n", tmp & 0x1, (tmp & 0x20) >> 5); tmp = mmio_readl(sb600_spibar); + /* FIXME: If SpiAccessMacRomEn or SpiHostAccessRomEn are zero on + * SB700 or later, reads and writes will be corrupted. Abort in this + * case. Make sure to avoid this check on SB600. + */ msg_pdbg("SpiArbEnable=%i, SpiAccessMacRomEn=%i, " "SpiHostAccessRomEn=%i, ArbWaitCount=%i, " "SpiBridgeDisable=%i, DropOneClkOnRd=%i\n", (tmp >> 19) & 0x1, (tmp >> 22) & 0x1, (tmp >> 23) & 0x1, (tmp >> 24) & 0x7, (tmp >> 27) & 0x1, (tmp >> 28) & 0x1); + tmp = (mmio_readb(sb600_spibar + 0xd) >> 4) & 0x3; + msg_pdbg("NormSpeed is %s MHz\n", speed_names[tmp]); /* Look for the SMBus device. */ smbus_dev = pci_dev_find(0x1002, 0x4385); @@ -230,6 +294,9 @@ return 0; } + /* Bring the FIFO to a clean state. */ + reset_internal_fifo_pointer(); + buses_supported |= CHIP_BUSTYPE_SPI; spi_controller = SPI_CONTROLLER_SB600; return 0; Modified: trunk/spi.h ============================================================================== --- trunk/spi.h Tue Aug 17 00:12:39 2010 (r1144) +++ trunk/spi.h Wed Aug 18 17:12:43 2010 (r1145) @@ -124,5 +124,6 @@ #define SPI_INVALID_ADDRESS -3 #define SPI_INVALID_LENGTH -4 #define SPI_FLASHROM_BUG -5 +#define SPI_PROGRAMMER_ERROR -6 #endif /* !__SPI_H__ */

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
21
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom August 2010