[LinuxBIOS] Grand flash chip challenge
c-d.hailfinger.devel.2006 at gmx.net
Tue Oct 23 20:06:46 CEST 2007
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.
More information about the coreboot