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 -- linuxbios mailing list [email protected] http://www.linuxbios.org/mailman/listinfo/linuxbios
