On Tue, 19 Mar 2013 16:12:43 +1100
James Cameron <quozl(a)laptop.org> wrote:
> G'day,
>
> I'm an Open Firmware developer working for One Laptop per Child.
>
> We have used the MX25U3235E chip in revision B1 of our XO-4 design,
> and I am trying to use flashrom (r1657) with a Bus Pirate to read from
> a chip.
>
> I see you pushed a patch for this chip in the past few days. A happy
> coincidence perhaps.
>
> Is there anything I can do to help you change TEST_UNTESTED to
> something else?
>
> (Sorry if this is an obvious question, but I have very little
> knowledge of flashrom, having used for the first time yesterday with a
> different chip. Mostly we program the chip from within Open
> Firmware.)
>
> I changed TEST_UNTESTED to TEST_OK_PR on my system, and captured the
> attached logs.
>
> While the identify worked, the read gave errors, and the output file
> contained 0xff only. We have never intentionally enabled any block
> protection on this chip.
>
Hello James,
the .tested field is only used for QA and telling the user about it.
Changing it does not influence functionality.
If you are in a hurry skip this paragraph. :)
I am a bit puzzled at the moment regarding the (read) log. If you look
at the detailed output of the contents of the status register at line
132 ff. you see that flashrom (mistakenly) reads 0xFF, which leads to
the assumption that a block protection is enabled (see bottom of page
26 in the datasheet of the chip; that's quite a standard layout of a
SPI flash status register...). It then tries to disable the
"protection" and fails because another bit in the status register - the
WIP bit - remains at 1.
I have no idea why it (always) reads 0xFF from the status register... I
have checked the opcode and it is correct, and there is nothing fancy
about... apart from one thing I just noticed which you could test:
in spi_read_status_register() in spi25_statusreg.c replace 2 with 1 in
the array declaration readarr[2] so that this line becomes
unsigned char readarr[1]; /* JEDEC_RDSR_INSIZE=1 but wbsio needs 2 */
wbsio is our driver for a very annoying winbond SPI master and as the
fixme in the function says, this hack should not be in the generic code.
If the macronix chip does not repeat the status register contents when
one reads more than one byte after sending the RDSR (read status
register) opcode (which chips usually do) but 0xFF then we have found
the culprit.
PS: please send further mails to flashrom(a)flashrom.org - our mailing
list, thanks.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Hi Vadim,
thanks for your mail. I have added the flashrom mailing list in CC:
because we should develop a generic way to handle DualBIOS and similar
techniques.
On 09.04.2010 08:12, Vadim Girlin wrote:
> I'm going to try coreboot on Gigabyte GA-MA770-UD3.
> It's AMD 770 (RX780 / SB700).
>
> My motherboard supports hardware dual bios - with two chips on it.
> I'm going to try flashing backup chip and boot from it. It seems to be
> possible - I've tested it (flashing at least). Chips on this board could
> be switched by changing bit 0 at undocumented register EF on LDN 7 of
> IT8720. I can use slightly patched flashrom for accessing any chip I
> want without any problems. And this is tested many times.
>
> My idea is to use backup chip for debugging - that always keeps my
> chance to reboot from main bios chip. And removes the need for
> desoldering etc.
>
> And second problem is that original bios is checking second chip - and
> trying to recover it by flashing the bios from main chip on reboot?
> rewriting coreboot. AFAICS this could be solved by including some
> signatures etc. It seems to be easy to find out. May be someone is
> working on this?
>
> BTW I can send the patch for flashrom - but I think that with
> information I mentioned above somebody could make it much better than my
> ugly hack. I hope the regs should be the same for all latest Gigabyte
> MBs using IT8720/18
>
It would be great if you could send that patch. It will help us make a
flashrom design decision that works for all boards with multiple flash
chips.
By the way, some of us have good contacts at ITE, so we can ask ITE for
details about the undocumented registers.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
The restricted opcode is not so unusual. We have encountered the same
with some thinkpads. Vendors don't need proper RDID because they
usually know which chip is installed so they don't have to support 300+
chips like flashrom does.
On Mon, 29 Apr 2013 14:47:35 +0400
Vasiliy Vylegzhanin <6vasia(a)gmail.com> wrote:
> 0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-write.
> 0x58: 0x07ff0580 FREG1: BIOS region (0x00580000-0x007fffff) is read-write.
> 0x5C: 0x057f0003 FREG2: Management Engine region (0x00003000-0x0057ffff) is read-write.
> 0x60: 0x00020001 FREG3: Gigabit Ethernet region (0x00001000-0x00002fff) is read-write.
> 0x64: 0x00000fff FREG4: Platform Data region is unused.
> 0x74: 0x00000000 (PR0 is unused)
> 0x78: 0x00000000 (PR1 is unused)
> 0x7C: 0x00000000 (PR2 is unused)
> 0x80: 0x87ff0770 PR3: WARNING: 0x00770000-0x007fffff is read-only.
> 0x84: 0x875f0580 PR4: WARNING: 0x00580000-0x0075ffff is read-only.
The protected regions are a bigger problem. This configuration protects
almost the complete BIOS region and this can not be disabled at
runtime. Does the vendor offer updates for the BIOS? Did you look into
the BIOS configuration menu if there is a switch to allow BIOS
modifications?
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
I've got a barebone pc from asus:
http://www.asus.com/Barebone_PCs/PunditR/
read flash looks ok perhaps dumps are a bit different
I've attached both from flashrom, original from asus in roms.tar.xz
other files:
info.tar.xz => lspci/lsusb/dmesg/dmidecode
read.log.xz => flashrom -r
write.log.xz => flashrom -w
Hope it helps
Regards
--
Gianluigi Tiesi <sherpya(a)netfarm.it>
EDP Project Leade
Netfarm S.r.l. - http://www.netfarm.it/
Free Software: http://oss.netfarm.it/
Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?
A non-text attachment roms.tar.xz has been stripped. It is available at
http://paste.flashrom.org/view.php?id=1709
Am 30.07.2013 23:22 schrieb Wei Hu:
> On Tue, Jul 30, 2013 at 1:59 PM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006(a)gmx.net> wrote:
>> This patch should work at normal speed and use the correct FIFO pointer
>> registers on Kabini.
>> The code is not exactly pretty, but functional and should (in theory)
>> need no functional changes before commit.
>>
>> Please check if read/write works at the expected speed. -VV is
>> sufficient this time.
>
> Reading the 4MB flash took 18 seconds, whereas writing took almost 3
> minutes. Is it normal? On another system with Intel PCH writes were
> way faster. There's another FIFO register at offset 0x80 in the new
> Kabini interface, which can hopefully speed up things, but the
> description is quite dense.
>
> I'm attaching two -VV logs, one from reading and the other from writing.
Thanks! This means my code works well.
The following timings are straight from the W25Q32BV datasheet. They may
be completely unrealistic. Typical erase time for that chip is around 30
seconds for a sectorwise chip erase (without overhead). The typical
write time for that chip (using 5-byte chunks due to the short FIFO for
SB600) would be around 600 seconds. Typical write time for that chip
with the long Kabini FIFO would be 45 seconds.
Add initial read time, sectorwise chip erase time, erase-verify time
(full chip read), write time, write-verify time (full chip read) and the
write time suddenly looks pretty reasonable.
Most important for me was to get the FIFO pointers right for Kabini.
Speed issues can be dealt with after the flashrom 0.9.7 release (right
now I'm just trying to fix things).
That said, the datasheet is rather unclear about the effect of
UseSpi100=1, and I'd like to set it to 0.
By the way, the data which enabled me to fix the FIFO stuff for Kabini
(because the datasheets have room for improvement) is here:
http://paste.flashrom.org/view.php?id=1718
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
Am 30.07.2013 20:55 schrieb Wei Hu:
> Attached is a log from flashrom -VVV -p internal -o /tmp/flashrom.log.
> Please let me know what else you want to collect.
Thanks!
> On Sun, Jul 28, 2013 at 3:38 PM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006(a)gmx.net> wrote:
>> Am 26.07.2013 23:31 schrieb Stefan Tauner:
>>> On Fri, 26 Jul 2013 12:28:48 -0700
>>> Wei Hu <wei(a)aristanetworks.com> wrote:
>>>> On Fri, Jul 26, 2013 at 12:18 AM, Carl-Daniel Hailfinger
>>>> <c-d.hailfinger.devel.2006(a)gmx.net> wrote:
>>>>>> I'll give you modified patch a test tomorrow.
>>>>> Please note that I expect problems with my patch. Not all of the FIFO
>>>>> management has been changed, and this might be the cause of error
>>>>> messages. Updated patch with more debugging at the end of this mail.
>>>> After changing the device ID to match 0x780e, your patch works for
>>>> both reading and writing. Writing is extremely slow though. I feel
>>>> like on this new FCH we should ditch the SB600 interface and
>>>> investigate the new programming interface. My current patch is more
>>>> like a band aid workaround.
>>> I plan to do that but for now it would be better than nothing, *but*
>>> this will break Hudson-2... I talked to Martin Roth from sage and he
>>> confirmed that although AMD changed PCI IDs with Hudson-1 the
>>> interface did only really change with Kabini/Temash.
>>>
>>> That explains also why Hudson-2 worked fine previously:
>>> http://marc.info/?l=flashrom&m=131853263731000
>>> Wang Qing Pei has tested his Hudson patch too probably before sending
>>> it to us but I don't know which system he used exactly.
>>>
>>> I'll try to get the Hudson-2 datasheets, but ATM I don't have them.
>>> We need a way to distinguish Kabini from the rest... since it is a SoC,
>>> we could match the pci ids of the root complex
>>> (00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] Family 16h
>>> Processor Root Complex [1022:1536] in my case), but we would need to
>>> maintain that for future models... Martin told me that they just read
>>> if the new registers are (non-)0xff and infer from that if they need to
>>> use the new interface.
>> New patch. Better heuristic (Martin's variant) for Kabini, more debug
>> prints.
>> The big challenge is to check whether this breaks Hudson variants before
>> Kabini.
>>
>> Please get some -VVV logs for a simple probe. Thanks!
>> # flashrom -o logfile.txt -VVV
>>
>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
This patch should work at normal speed and use the correct FIFO pointer
registers on Kabini.
The code is not exactly pretty, but functional and should (in theory)
need no functional changes before commit.
Please check if read/write works at the expected speed. -VV is
sufficient this time.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Index: flashrom-kabini/sb600spi.c
===================================================================
--- flashrom-kabini/sb600spi.c (Revision 1704)
+++ flashrom-kabini/sb600spi.c (Arbeitskopie)
@@ -4,7 +4,7 @@
* Copyright (C) 2008 Wang Qingpei <Qingpei.Wang(a)amd.com>
* Copyright (C) 2008 Joe Bao <Zheng.Bao(a)amd.com>
* Copyright (C) 2008 Advanced Micro Devices, Inc.
- * Copyright (C) 2009, 2010 Carl-Daniel Hailfinger
+ * Copyright (C) 2009, 2010, 2013 Carl-Daniel Hailfinger
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -45,6 +45,8 @@
static uint8_t *sb600_spibar = NULL;
+static int kabini_method = 0;
+
static void reset_internal_fifo_pointer(void)
{
mmio_writeb(mmio_readb(sb600_spibar + 2) | 0x10, sb600_spibar + 2);
@@ -54,33 +56,67 @@
msg_pspew("reset\n");
}
-static int compare_internal_fifo_pointer(uint8_t want)
+static int check_internal_fifo_pointer(uint8_t have, uint8_t want)
{
+ if (have != want) {
+ msg_perr("AMD SPI FIFO pointer corruption! Pointer is %d, wanted %d\n", have, want);
+ msg_perr("Something else is accessing the flash chip and causes random corruption.\n"
+ "Please stop all applications and drivers and IPMI which access the flash chip.\n");
+ return 1;
+ }
+ msg_pspew("AMD SPI FIFO pointer is %d, wanted %d\n", have, want);
+ return 0;
+}
+
+static int compare_internal_kabini_fifo_write_pointer(uint8_t want)
+{
uint8_t tmp;
+ tmp = mmio_readb(sb600_spibar + 0x4d) & 0x7f;
+ return check_internal_fifo_pointer(tmp, want);
+}
+
+static int compare_internal_kabini_fifo_read_pointer(uint8_t want)
+{
+ uint8_t tmp;
+
+ tmp = mmio_readb(sb600_spibar + 0x4e) & 0x7f;
+ return check_internal_fifo_pointer(tmp, want);
+}
+
+static int compare_internal_sb600_fifo_pointer(uint8_t want)
+{
+ uint8_t tmp;
+
tmp = mmio_readb(sb600_spibar + 0xd) & 0x07;
want &= 0x7;
- if (want != tmp) {
- msg_perr("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;
- }
+ return check_internal_fifo_pointer(tmp, want);
}
+#if 0
static int reset_compare_internal_fifo_pointer(uint8_t want)
{
int ret;
+#if 0
+ if (kabini_method) {
+ uint8_t tmp1;
+ mmio_writeb(7, sb600_spibar + 0x1e);
+ tmp = mmio_readb(sb600_spibar + 0x1f);
+ msg_pspew("Kabini SPIDataFifoPtr %d/%d, ", tmp, want);
+ tmp = mmio_readb(sb600_spibar + 0xd) & 0x07;
+ msg_pspew("FifoPtr %d/%d, ", tmp, want & 0x07);
+ tmp = mmio_readb(sb600_spibar + 0x4d) & 0x7f;
+ tmp1 = mmio_readb(sb600_spibar + 0x4e) & 0x7f;
+ msg_pspew("FifoWrPtr/FifoRdPtr %d/%d\n", tmp, tmp1);
+ }
+#endif
+
ret = compare_internal_fifo_pointer(want);
reset_internal_fifo_pointer();
return ret;
}
+#endif
static void execute_command(void)
{
@@ -99,7 +135,7 @@
/* First byte is cmd which can not being sent through FIFO. */
unsigned char cmd = *writearr++;
unsigned int readoffby1;
- unsigned char readwrite;
+ unsigned char readwrite = 0;
writecnt--;
@@ -118,15 +154,21 @@
return SPI_INVALID_LENGTH;
}
- /* 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
- * the chip response is discarded and will not end up in the FIFO.
- * It is unclear if the CS# line is set high too early as well.
- */
- readoffby1 = (writecnt) ? 0 : 1;
- readwrite = (readcnt + readoffby1) << 4 | (writecnt);
- mmio_writeb(readwrite, sb600_spibar + 1);
+ if (kabini_method) {
+ /* Use the extended TxByteCount and RxByteCount register. */
+ mmio_writeb(writecnt, sb600_spibar + 0x48);
+ mmio_writeb(readcnt, sb600_spibar + 0x4b);
+ } else {
+ /* 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
+ * the chip response is discarded and will not end up in the FIFO.
+ * It is unclear if the CS# line is set high too early as well.
+ */
+ readoffby1 = (writecnt) ? 0 : 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. */
@@ -139,16 +181,29 @@
mmio_writeb(*writearr, sb600_spibar + 0xC);
}
msg_pspew("\n");
+ if (kabini_method) {
+ if (compare_internal_kabini_fifo_write_pointer(writecnt))
+ return SPI_PROGRAMMER_ERROR;
+ } else {
+ if (compare_internal_sb600_fifo_pointer(writecnt))
+ return SPI_PROGRAMMER_ERROR;
+ }
/*
* We should send the data by sequence, which means we need to reset
* the FIFO pointer to the first byte we want to send.
*/
- if (reset_compare_internal_fifo_pointer(writecnt))
- return SPI_PROGRAMMER_ERROR;
+ reset_internal_fifo_pointer();
msg_pspew("Executing: \n");
execute_command();
+ if (kabini_method) {
+ if (compare_internal_kabini_fifo_write_pointer(writecnt + readcnt))
+ return SPI_PROGRAMMER_ERROR;
+ } else {
+ if (compare_internal_sb600_fifo_pointer(writecnt + readcnt))
+ return SPI_PROGRAMMER_ERROR;
+ }
/*
* After the command executed, we should find out the index of the
@@ -161,8 +216,7 @@
* the opcode, the FIFO already stores the response from the chip.
* Usually, the chip will respond with 0x00 or 0xff.
*/
- if (reset_compare_internal_fifo_pointer(writecnt + readcnt))
- return SPI_PROGRAMMER_ERROR;
+ reset_internal_fifo_pointer();
/* Skip the bytes we sent. */
msg_pspew("Skipping: ");
@@ -171,27 +225,53 @@
msg_pspew("[%02x]", cmd);
}
msg_pspew("\n");
- if (compare_internal_fifo_pointer(writecnt))
- return SPI_PROGRAMMER_ERROR;
+ if (kabini_method) {
+ if (compare_internal_kabini_fifo_read_pointer(writecnt))
+ return SPI_PROGRAMMER_ERROR;
+ } else {
+ if (compare_internal_sb600_fifo_pointer(writecnt))
+ return SPI_PROGRAMMER_ERROR;
+ }
+
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;
+ if (kabini_method) {
+ if (compare_internal_kabini_fifo_read_pointer(writecnt + readcnt))
+ return SPI_PROGRAMMER_ERROR;
+ } else {
+ if (compare_internal_sb600_fifo_pointer(writecnt + readcnt))
+ return SPI_PROGRAMMER_ERROR;
}
+ reset_internal_fifo_pointer();
+ if (kabini_method) {
+ uint8_t tmp_wc = mmio_readb(sb600_spibar + 0x48);
+ uint8_t tmp_rc = mmio_readb(sb600_spibar + 0x4b);
+ if ((tmp_rc != readcnt) || (tmp_wc != writecnt)) {
+ msg_perr("Unexpected change in Kabini read/write count: %i/%i instead of %i/%i!\n",
+ tmp_rc, tmp_wc, readcnt, writecnt);
+ msg_perr("Something else is accessing the flash chip and causes random corruption.\n"
+ "Please stop all applications and drivers and IPMI which access the flash "
+ "chip.\n");
+ return SPI_PROGRAMMER_ERROR;
+ }
+ } else {
+ uint8_t tmp_rw = mmio_readb(sb600_spibar + 1);
+ if (tmp_rw != readwrite) {
+ msg_perr("Unexpected change in SB600 read/write count: %i instead of %i!\n", tmp_rw,
+ readwrite);
+ msg_perr("Something else is accessing the flash chip and causes random corruption.\n"
+ "Please stop all applications and drivers and IPMI which access the flash "
+ "chip.\n");
+ return SPI_PROGRAMMER_ERROR;
+ }
+ }
return 0;
}
@@ -245,8 +325,8 @@
uint32_t tmp;
uint8_t reg;
bool amd_imc_force = false;
- static const char *const speed_names[4] = {
- "66/reserved", "33", "22", "16.5"
+ static const char *const speed_names[8] = {
+ "66 MHz", "33 MHz", "22 MHz", "16.6 MHz", "100 MHz", "Reserved", "Reserved", "800 kHz"
};
char *arg = extract_programmer_param("amd_imc_force");
@@ -281,6 +361,30 @@
*/
sb600_spibar += tmp & 0xfff;
+ /* AMD Kabini has a different SPI interface. */
+ kabini_method = 0;
+ if (dev->device_id == 0x780e) {
+ /* The PCI ID of the LPC bridge doesn't change between Hudson-2 and Kabini (Hudson-3) although
+ * they use different SPI interfaces. ID 0x780e is common for all Hudson variants. This
+ * heuristic accesses the SPI interface MMIO BAR at locations beyond those supported by
+ * Hudson-2 and earlier in the hope of getting 0xff readback on older chipsets and non-0xff
+ * readback on Kabini and newer chipsets.
+ */
+ int i;
+ msg_pdbg("Checking for AMD Kabini or later... ");
+ for (i = 0x20; i <= 0x4f; i++) {
+ if (mmio_readb(sb600_spibar + i) != 0xff) {
+ kabini_method = 1;
+ break;
+ }
+ }
+ if (kabini_method)
+ msg_pdbg("using AMD Kabini SPI access method.\n");
+ else
+ msg_pdbg("not found.\n");
+ }
+
+ /* FIXME: Check all accesses below for Kabini incompatibilities. */
tmp = pci_read_long(dev, 0xa0);
msg_pdbg("AltSpiCSEnable=%i, SpiRomEnable=%i, "
"AbortEnable=%i\n", tmp & 0x1, (tmp & 0x2) >> 1,
@@ -300,15 +404,28 @@
* SB700 or later, reads and writes will be corrupted. Abort in this
* case. Make sure to avoid this check on SB600.
*/
- msg_pdbg("(0x%08" PRIx32 ") fastReadEnable=%u, SpiArbEnable=%i, SpiAccessMacRomEn=%i, "
+ msg_pdbg("(0x%08" PRIx32 ") SpiReadMode/FastReadEnable=%i, SpiArbEnable=%i, SpiAccessMacRomEn=%i, "
"SpiHostAccessRomEn=%i, ArbWaitCount=%i, "
- "SpiBridgeDisable=%i, DropOneClkOnRd=%i\n",
- tmp, (tmp >> 18) & 0x1,
+ "SpiBridgeDisable=%i, SpiClkGate/DropOneClkOnRd=%i\n",
+ tmp, ((tmp >> 28) & 0x6) | ((tmp >> 18) & 0x1),
(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]);
+ if (kabini_method) {
+ tmp = mmio_readb(sb600_spibar + 0x20) & 0x1;
+ msg_pdbg("UseSpi100 is %i (%s)\n", tmp, tmp ? "unsupported" : "OK");
+ tmp = mmio_readw(sb600_spibar + 0x22);
+ msg_pdbg("TpmSpeedNew is %s\n", speed_names[tmp & 0xf]);
+ tmp >>= 4;
+ msg_pdbg("AltSpeedNew is %s\n", speed_names[tmp & 0xf]);
+ tmp >>= 4;
+ msg_pdbg("FastSpeedNew is %s\n", speed_names[tmp & 0xf]);
+ tmp >>= 4;
+ msg_pdbg("NormSpeedNew is %s\n", speed_names[tmp & 0xf]);
+ } else {
+ 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);
--
http://www.hailfinger.org/
flashrom v0.9.6.1-r1564 on Linux 2.6.18-348.12.1.el5 (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found chipset "Intel Lynx Point".
This chipset is marked as untested. If you are using an up-to-date version
of flashrom *and* were (not) able to successfully update your firmware with
it,
then please email a report to flashrom(a)flashrom.org including a verbose (-V)
log.
Thank you!
Enabling flash write... enable_flash_ich_dc_spi: unknown ICH generation.
Please report!
WARNING: SPI Configuration Lockdown activated.
Enabling hardware sequencing because some important opcode is locked.
OK.
Found Programmer flash chip "Opaque flash chip" (16384 kB,
Programmer-specific) at physical address 0x0.
Flash image seems to be a legacy BIOS. Disabling coreboot-related checks.
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... VERIFIED.
flashrom v0.9.6.1-r1564 on Linux 2.6.18-348.12.1.el5 (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org
flashrom was built with libpci 3.1.7, GCC 4.1.2 20080704 (Red Hat 4.1.2-54),
little endian
Command line (2 args): flashrom -V --programmer=internal
Calibrating delay loop... OS timer resolution is 1 usecs, 3365M loops per
second, 10 myus = 10 us, 100 myus = 106 us, 1000 myus = 1014 us, 10000 myus
= 10006 us, 4 myus = 6 us, OK.
Initializing internal programmer
No coreboot table found.
DMI string system-manufacturer: "MSI"
DMI string system-product-name: "MS-7816"
DMI string system-version: "1.0"
DMI string baseboard-manufacturer: "MSI"
DMI string baseboard-product-name: "H87-G43 (MS-7816)"
DMI string baseboard-version: "1.0"
DMI string chassis-type: "Desktop"
Found chipset "Intel Lynx Point" with PCI ID 8086:8c4a.
This chipset is marked as untested. If you are using an up-to-date version
of flashrom *and* were (not) able to successfully update your firmware with
it,
then please email a report to flashrom(a)flashrom.org including a verbose (-V)
log.
Thank you!
Enabling flash write... enable_flash_ich_dc_spi: unknown ICH generation.
Please report!
0x7fffffff/0x7fffffff FWH IDSEL: 0x0
0x7fffffff/0x7fffffff FWH IDSEL: 0x0
0x7fffffff/0x7fffffff FWH IDSEL: 0x1
0x7fffffff/0x7fffffff FWH IDSEL: 0x1
0x7fffffff/0x7fffffff FWH IDSEL: 0x2
0x7fffffff/0x7fffffff FWH IDSEL: 0x2
0x7fffffff/0x7fffffff FWH IDSEL: 0x3
0x7fffffff/0x7fffffff FWH IDSEL: 0x3
0x7fffffff/0x7fffffff FWH IDSEL: 0x4
0x7fffffff/0x7fffffff FWH IDSEL: 0x5
0x7fffffff/0x7fffffff FWH IDSEL: 0x6
0x7fffffff/0x7fffffff FWH IDSEL: 0x7
0x7fffffff/0x7fffffff FWH decode enabled
0x7fffffff/0x7fffffff FWH decode enabled
0x7fffffff/0x7fffffff FWH decode enabled
0x7fffffff/0x7fffffff FWH decode enabled
0x7fffffff/0x7fffffff FWH decode enabled
0x7fffffff/0x7fffffff FWH decode enabled
0x7fffffff/0x7fffffff FWH decode enabled
0x7fffffff/0x7fffffff FWH decode enabled
0x7fffffff/0x7fffffff FWH decode enabled
0x7fffffff/0x7fffffff FWH decode enabled
0x7fffffff/0x7fffffff FWH decode enabled
0x7fffffff/0x7fffffff FWH decode enabled
Maximum FWH chip size: 0x100000 bytes
BIOS Lock Enable: disabled, BIOS Write Enable: disabled, BIOS_CNTL is 0x8
Root Complex Register Block address = 0xfed1c000
GCS = 0xc65: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3
(unknown)
Top Swap : not enabled
SPIBAR = 0xfed1c000 + 0x3800
0x04: 0xf008 (HSFS)
HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1
WARNING: SPI Configuration Lockdown activated.
Reading OPCODES... done
0x06: 0x3f00 (HSFC)
HSFC: FGO=0, FCYCLE=0, FDBC=63, SME=0
0x08: 0x00ffffc0 (FADDR)
0x50: 0x0000ffff (FRAP)
BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff
0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is
read-write.
0x58: 0x0fff0a00 FREG1: BIOS region (0x00a00000-0x00ffffff) is read-write.
0x5C: 0x09ff0001 FREG2: Management Engine region (0x00001000-0x009fffff) is
read-write.
0x90: 0xc0 (SSFS)
SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0
0x91: 0xfc4010 (SSFC)
SSFC: SCGO=0, ACS=0, SPOP=0, COP=1, DBC=0, SME=0, SCF=4
0x94: 0x0006 (PREOP)
0x96: 0x043b (OPTYPE)
0x98: 0x05203b02 (OPMENU)
0x9C: 0x0000019f (OPMENU+4)
0xA0: 0x00000000 (BBAR)
0xC4: 0x80802025 (LVSCC)
LVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=1
0xC8: 0x00002025 (UVSCC)
UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=0
0xD0: 0x50444653 (FPB)
Enabling hardware sequencing because some important opcode is locked.
SPI Read Configuration: prefetching enabled, caching enabled, OK.
The following protocols are supported: FWH, Programmer-specific.
Probing for Programmer Opaque flash chip, 0 kB: Found 1 attached SPI flash
chip with a density of 16384 kB.
The flash address space (0x000000 - 0x9acfff) is divided at address 0x653000
in two partitions.
The first partition ranges from 0x000000 to 0x652fff.
In that range are 1619 erase blocks with 4096 B each.
The second partition ranges from 0x653000 to 0x9acfff.
In that range are 2477 erase blocks with 4096 B each.
Found Programmer flash chip "Opaque flash chip" (16384 kB,
Programmer-specific) at physical address 0x0.
Probing for Atmel AT49LH002, 256 kB: probe_82802ab: id1 0xff, id2 0xff, id1
parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Intel 82802AB, 512 kB: probe_82802ab: id1 0xed, id2 0x88, id1
parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Intel 82802AC, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1
parity violation, id1 is normal flash content, id2 is normal flash content
Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0xff, id2 0xff,
id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0xed, id2 0x88,
id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for Sharp LHF00L04, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1
parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF002A/B, 256 kB: probe_jedec_common: id1 0xff, id2
0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for SST SST49LF003A/B, 384 kB: probe_jedec_common: id1 0x00, id2
0x03, id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for SST SST49LF004A/B, 512 kB: probe_jedec_common: id1 0xed, id2
0x88, id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for SST SST49LF004C, 512 kB: probe_82802ab: id1 0xed, id2 0x88, id1
parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF008A, 1024 kB: probe_jedec_common: id1 0xff, id2
0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for SST SST49LF008C, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1
parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF016C, 2048 kB: Chip size 2048 kB is bigger than
supported size 1024 kB of chipset/board/programmer for FWH interface,
probe/read/erase/write may fail. probe_82802ab: id1 0x2d, id2 0xbd, id1
parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW040A, 512 kB: probe_82802ab: id1 0xed, id2 0x88, id1
parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0xed, id2 0x88, id1
parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW080A, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1
parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW080B, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1
parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW002, 256 kB: probe_82802ab: id1 0xff, id2 0xff, id1
parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW016, 2048 kB: Chip size 2048 kB is bigger than supported
size 1024 kB of chipset/board/programmer for FWH interface,
probe/read/erase/write may fail. probe_82802ab: id1 0x2d, id2 0xbd, id1
parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW040, 512 kB: probe_82802ab: id1 0xed, id2 0x88, id1
parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW080, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1
parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W39V040FA, 512 kB: probe_jedec_common: id1 0xed, id2
0x88, id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0xed, id2
0x88, id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for Winbond W39V040FC, 512 kB: probe_jedec_common: id1 0xed, id2
0x88, id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for Winbond W49V002FA, 256 kB: probe_jedec_common: id1 0xff, id2
0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for Winbond W39V080FA, 1024 kB: probe_jedec_common: id1 0xff, id2
0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for Winbond W39V080FA (dual mode), 512 kB: probe_jedec_common: id1
0xed, id2 0x88, id1 parity violation, id1 is normal flash content, id2 is
normal flash content
Found Programmer flash chip "Opaque flash chip" (16384 kB,
Programmer-specific).
No operations were specified.
Restoring MMIO space at 0x2b92ee7ee8a0
Restoring PCI config space for 00:1f:0 reg 0xdc