Re: [flashrom] Issue with internal access to the W39V040FB

[Stefan Tauner]

On Fri, 1 Jan 2016 16:18:17 +0300
Andrey Korolyov  wrote:
> Hello and Happy New Year,
>
> a couple of days ago I acquired an old GeodeLX-based thin client
> TONK-1202/ТОНК-1202 (cyr) for a purpose to put coreboot on it, because
> board is very simular to existing ones in the coreboot tree and there
> should be no big deal to make a port. Aside from very funny issue that
> I am not able to boot modern 2.6.18+ i386 Linux kernel on it (ALIX
> Geode board said to have same issue [0], but it has been reportedly
> fixed by a vendor bios update), all other Linux variants (2.4.xx and
> 2.6.13) and NetBSD 7.0 are somehow messing with the internal
> interface, with no positive outcome as a result:
>
> ./flashrom -p internal:laptop=this_is_not_a_laptop -c W39V040FB -r bios.bin -V
> ....
> Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0x25,
> id2 0x6b, id1 is normal flash content, id2 is normal flash content
> No EEPROM/flash device found
> ...
>
> NetBSD 5.1 with same flashrom version working just well, I was able to
> read the chip contents and write them back without any issues. This is
> not a blocker, as I would stick to the external programmer anyway, but
> probably worth investigating as a regression - monolithic nature of
> NetBSD releases and very limited board performance would not allow to
> bisect this easily, so it`s better to narrow a debug field, if
> possible, in advance.

Hi Andrey,

please post complete logs of a working and non-working probe as well as
the exact flashrom version you are using. The output of lspci -nnv
might become handy as well.

Issue with internal access to the W39V040FB

[Andrey Korolyov]

> Hi Andrey,
>
> please post complete logs of a working and non-working probe as well as
> the exact flashrom version you are using. The output of lspci -nnv
> might become handy as well.

Thanks Stefan,

even giving out a fact that I am very lucky to hit very twisted issues
at all, this time it looks like chip eventually stopped to respond via
an appropriate interface (slight voltage change? bit-flip during a
board initialization? lack of a probe delay? ), so I think that the
initial report could be incorrect, as the flash is not responding
anymore even where is was supposed to. Nevertheless, the appropriate
log and lspci output are attached, please take a look on them if they
could be helpful.