[LinuxBIOS] Grand flash chip challenge

[Carl-Daniel Hailfinger]

Hi,

during my flash chip usage research I found a few chips which are not
yet supported by flashrom. Unfortunately, I have neither data sheets nor
part numbers for most of them. Here's the challenge: Find the data sheet
and part number for the following chips:

* Vendor CATALYST with vendor ID 0x31, part ID 0x96 (probably 3 MBit)
* Vendor ST with vendor ID 0x20, part ID 0x2c (probably 4 MBit)
* Vendor WINBOND with vendor ID 0xda, part ID 0xb0 (probably 8 MBit)

However, it is possible that the CATALYST and WINBOND chips do not exist
and flashrom produced garbage in a very consistent way.

Have fun!
Carl-Daniel

[Peter Lemenkov]

2007/10/23, Carl-Daniel Hailfinger :
> Vendor CATALYST with vendor ID 0x31, part ID 0x96 (probably 3 MBit)
> Vendor ST with vendor ID 0x20, part ID 0x2c (probably 4 MBit)

M50FW040/3V (FWH), 512 Kbytes, page size 128 bytes, 8x64Kbyte sectors
> Vendor WINBOND with vendor ID 0xda, part ID 0xb0 (probably 8 MBit)

W49V002(A)/3.3V (LPC), 256 kbytes.

All data gathered from Uniflash sources.

BTW why we still not import all data from this wonderful GPL'ed
utility? There are tons of information, and Uniflash greatly
surpassing flashrom in case of supported hardware.
> However, it is possible that the CATALYST and WINBOND chips do not exist
> and flashrom produced garbage in a very consistent way.
>
> Have fun!
> Carl-Daniel

[Stefan Reinauer]

Peter Lemenkov wrote:
> BTW why we still not import all data from this wonderful GPL'ed
> utility? There are tons of information, and Uniflash greatly
> surpassing flashrom in case of supported hardware.

I guess its because it doesn't make a lot of sense to import tons of
untested and untestable code.
This would give people a wrong impression about what we think will work
and what will not.

If people see their HW supported in uniflash, using uniflash is probably
a great idea.

We get very few reports of unsupported hardware in flashrom, so I guess
flashrom support is not the most pressing issue.

If you wish to port flash devices over from uniflash and you can test
them on real hardware, that will be highly appreciated.

Another cool thing would be to fix the current flashchip code and
structure to be able to cope with partial writes _properly_ and
_cleanly_ rather than rewriting the whole chip, or the crappy approaches
used now. So flashrom could be used to safely update only the normal
image of your bios..

Currently a power loss during flashing might well mean loss of the
fallback image. :-(

Stefan

[Carl-Daniel Hailfinger]

On 23.10.2007 19:27, Stefan Reinauer wrote:
> Peter Lemenkov wrote:
> > BTW why we still not import all data from this wonderful GPL'ed
> > utility? There are tons of information, and Uniflash greatly
> > surpassing flashrom in case of supported hardware.
>
> I guess its because it doesn't make a lot of sense to import tons of
> untested and untestable code.
> This would give people a wrong impression about what we think will work
> and what will not.
>
> If people see their HW supported in uniflash, using uniflash is probably
> a great idea.

Depends. If someone manages to get uniflash working under Linux, it
might be a good idea to use it. OTOH, flashrom is a native Linux/*BSD
tool and works fine for a lot of chips as well.
> We get very few reports of unsupported hardware in flashrom, so I guess
> flashrom support is not the most pressing issue.
>
> If you wish to port flash devices over from uniflash and you can test
> them on real hardware, that will be highly appreciated.

Even if they can not be tested, adding support to recognize them (no
write/erase) would help a lot to broaden our user base. That way, people
can tell us about a chip they have without opening the case.
> Another cool thing would be to fix the current flashchip code and
> structure to be able to cope with partial writes _properly_ and
> _cleanly_ rather than rewriting the whole chip, or the crappy approaches
> used now. So flashrom could be used to safely update only the normal
> image of your bios..

I have not yet looked at the partial write support for parallel flash.
Can you tell me what is crappy with the current approach? I see it has
some limits (especially when handling non-uniform block size), but for
uniform block size it should work well AFAICS.
> Currently a power loss during flashing might well mean loss of the
> fallback image. :-(

That's something I will fix, at least for serial flash.

Carl-Daniel

[Uwe Hermann]

On Tue, Oct 23, 2007 at 08:06:46PM +0200, Carl-Daniel Hailfinger wrote:
> Even if they can not be tested, adding support to recognize them (no
> write/erase) would help a lot to broaden our user base. That way, people

ACK. Detection support alone is useful per se. However, we should then
distinguish between known-to-work and only-detected-but-no-idea-if-it-works
in the list of supported chips.

Uwe.