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