Am Montag, den 19.12.2011, 17:15 +0000 schrieb Owens, Nathan D:
I've been trying to flash the SST49LF160C on my ms-7135. Fails to verify with the same problem every time (see attached).
Oddly, when I use this board's original chip (SST49LF004A/B), flashing verifies without a problem.
You seem to have encountered either a bug in flashrom or a limit of your mainboard, but I suspect the former. A problem with nVidia chipsets is that there seems to be no public documentation about the register bits.
The issue you are facing is that you have an address decoding problem: While the ROM address space of 2MB of your new chip is decoded correctly (otherwise the probe would fail, as we probe at the low end of the address space), the register dump looks suspicious:
lockbits at address=0xb7154002 is 0xff lockbits at address=0xb7164002 is 0xff [...] lockbits at address=0xb7244002 is 0xff lockbits at address=0xb7254002 is 0x0 lockbits at address=0xb7264002 is 0x0 lockbits at address=0xb7334002 is 0x0 [...] lockbits at address=0xb7344002 is 0x0 lockbits at address=0xb734c002 is 0x0 lockbits at address=0xb734e002 is 0x0 lockbits at address=0xb7350002 is 0x0
The lockbits on this chip are accessed in a separate address space, called the "register space", and should never read 0xff. So it is quite likely that the reads returning 0xff are not routed to the ROM chip at all, indacting a wrongly configured decoding. Only 1MB of register space is decoded.
As your chip defaults to read-only, and you have to unlock it (which flashrom tries through the register space), it will fail to unlock the areas of the flash chip having lock registers that are inaccessible to the processor. So the first half of your 2MB chip is read-only, and writing to it fails.
Any ideas?
Most likely, we need to reprogram the south bridge to route a larger address space to the flash chip (just hoping that no PCI component has been mapped at that area, which is at 0xFFA00000 .. 0xFFAFFFFF for the unrouted half of the flash chip while 0xFFB00000 .. 0xFFBFFFFF) is routed to the flash chip.
Please post the output of lspci -nnvvvxxx (run as root)
Thanks in advance, Michael Karcher
Here is the output for lspci -nnvvvxxx (run as root). Let me know if you'd like me to do anything else. I'm not really a programmer, but I know my way around the command line and am a bit of a sysadmin.
Nathan Owens
Am Montag, den 19.12.2011, 17:15 +0000 schrieb Owens, Nathan D:
I've been trying to flash the SST49LF160C on my ms-7135. Fails to verify with the same problem every time (see attached).
Oddly, when I use this board's original chip (SST49LF004A/B), flashing verifies without a problem.
You seem to have encountered either a bug in flashrom or a limit of your mainboard, but I suspect the former. A problem with nVidia chipsets is that there seems to be no public documentation about the register bits.
The issue you are facing is that you have an address decoding problem: While the ROM address space of 2MB of your new chip is decoded correctly (otherwise the probe would fail, as we probe at the low end of the address space), the register dump looks suspicious:
lockbits at address=0xb7154002 is 0xff lockbits at address=0xb7164002 is 0xff [...] lockbits at address=0xb7244002 is 0xff lockbits at address=0xb7254002 is 0x0 lockbits at address=0xb7264002 is 0x0 lockbits at address=0xb7334002 is 0x0 [...] lockbits at address=0xb7344002 is 0x0 lockbits at address=0xb734c002 is 0x0 lockbits at address=0xb734e002 is 0x0 lockbits at address=0xb7350002 is 0x0
The lockbits on this chip are accessed in a separate address space, called the "register space", and should never read 0xff. So it is quite likely that the reads returning 0xff are not routed to the ROM chip at all, indacting a wrongly configured decoding. Only 1MB of register space is decoded.
As your chip defaults to read-only, and you have to unlock it (which flashrom tries through the register space), it will fail to unlock the areas of the flash chip having lock registers that are inaccessible to the processor. So the first half of your 2MB chip is read-only, and writing to it fails.
Any ideas?
Most likely, we need to reprogram the south bridge to route a larger address space to the flash chip (just hoping that no PCI component has been mapped at that area, which is at 0xFFA00000 .. 0xFFAFFFFF for the unrouted half of the flash chip while 0xFFB00000 .. 0xFFBFFFFF) is routed to the flash chip.
Please post the output of lspci -nnvvvxxx (run as root)
Thanks in advance, Michael Karcher
-
Michael Karcher -
Nathan Owens