Hi,
On 24.03.2018 13:49, awokd via flashrom wrote:
Having trouble getting a good read from a Macronix MX25L3206E in situ Thinkpad E420 Sandy Bridge/Cougar Point PCH. Don't believe it's a programmer problem because I used the same programmer and pinouts to successfully flash a Winbond W25Q32.V in a different system.
I found the Wistron LLW-1/LGG-1 schematic and matched the flash chip up with the silk-screened label. Tried it in system with system power. I've pulled the board and RAM. Also tried removing CPU. Symptoms of the problem are:
- On system power, doesn't detect chip.
- Using an external PS, when I restrict the current to the point there's a
vdroop to ~3.0v-3.2v, flashrom detects the chip. If I give it more current (at 3.3v), the chip disappears and flashrom no longer sees it.
- Occasionally it acts like a successful read, WRSR updates correctly but
resulting file is mostly FF with a section of pages of 00 and some with alternating bit patterns. Oddly, the file is consistent over multiple runs and diff reports no differences, but there is nothing in it that looks like actual data and ifdtool says there's no descriptor.
I haven't fully followed the power rails in the schematics. Though, what you witnessed sounds much like you also power the PCH and maybe the EC too. The overall board layout regarding the SPI flash looks astonishing. I wonder why it works at all ;)
You might already know the `laptop=force_I_want_a_brick` option for internal flashing. This option was introduced because of severe trouble with *less* complex situations. It looks like Wistron already placed two masters on the SPI bus (it should only be one) and your programmer is the third.
If I understand things correctly, the flash chip is shared as much as possible (understandable for such a cheap machine). 1. the EC stores its firmware in it. 2. the ME loads some of its firmware directly over SPI. 3. the BIOS is loaded over LPC through the EC (that's the I_want_ a_brick scenario). My vague guess is that it only works because the EC can somehow predict when the ME is going to access the SPI flash (e.g. within some ms after enabling certain power rails).
I see three solutions here:
1. Desolder the flash chip completely. If you just want to flash once, solder it back afterwards. Otherwise, add some isolation circuit. 2. Replace R6010 and R6011 with diodes. Make sure to remove all bat- teries and AC, and power the flash chip directly during programming. 3. Cut the VCC pin of the flash chip, solder it together again later (I've heard people are doing that).
My personal choice would be 2., I would never try 3. (chances are too high that you hurt the pad below the VCC pin).
Alternatively, I see in the SPI programming guide there might be a couple other ways to disable ME?
- Temporarily disable the Intel® ME through the MEBX. Power off or cold
reset. - This option is only applicable to non-Intel ME Ignition firmware.
Won't help, it's only useful for internal flashing.
- HDA_SDO(Manufacturing mode jumper or Flash descriptor override jumper)
asserted HIGH on the rising edge of PWROK. Power off or cold reset. Note: this is only valid as long as you do not specifically set the variable Flash Descriptor Overrride Pin-Strap Ignore in the Flash Image Tool to false.
Might not help either, datasheet says ME would still do some chipset bring-up. Also only if the ME really is the problematic part. If the EC wakes up, that's a different story.
Nico