[flashrom] In situ Thinkpad E420 Sandy Bridge/Cougar Point PCH

[Nico Huber]

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?
> 
> 1. 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.

> 2. 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