On Fri, 02 Sep 2011 11:48:10 +0100 Andrew Goodbody andrew.goodbody@tadpole.com wrote:
On 09/01/11 22:20, Uwe Hermann wrote:
Hi,
Acked-by: Uwe Hermannuwe@hermann-uwe.de
but please see below for a review.
On Thu, Sep 01, 2011 at 01:37:48AM +0200, Stefan Tauner wrote:
- add P7H55-M LX to the list of supported boards although flashrom works correctly, it is marked as not ok, because flashing the vendor image will break the LAN interface.
Hm, dunno if this is what we want to do, the "board loses MAC address" issue happens for other boards too and is not strictly flashrom related.
I disagree. If the use of flashrom results in reduced functionality, as in this case, then that is strictly a flashrom problem. We must warn users about this for all affected boards, IMO.
i think warning the user when we are aware of board-specific problems is out of the question. but who is to blame is not so clear. flashrom has one single purpose (imho): read and write files from and to flash chips. it does not fail to accomplish this on the affected boards at all. but writing the image is not enough to update the firmware on those boards. of course a user that want to just update the firmware with a free and open tool does not care too much who to blame, but it is important for us to decide if this is in the scope of flashrom or not.
imho flashrom (or more specifically libflashrom) should NOT care, but another layer that has much more knowledge about bios files/layouts and board-specifics should handle this. this can be a dedicated ui for updating mainboard firmwares (not necessarily a gui like qflashrom. it could be a script that just prepares the image before calling flashrom.) or another library "libpcfirmware" or so that handles nvram backups, mac addresses etc. and can be used together with libflashrom to build a fully fledged pc updater.
the reason for this is that (lib)flashrom was extended a lot since it was started and the functionality of the current source is more focused on "read and write files from and to flash chips no matter how they are accessible" than on "update firmware of pcs". this focus may shift again when we are concentrating on laptop support though. also, the above-mentioned libpcfirmware does not necessarily need to be another distinct project from flashrom: i just think it makes sense to have clear responsibilities and interfaces. and also that the current cli interface slowly grows to something that is too big to grasp (man page) and use for normal end users that just want to update their pcs, but OTOH is needed for more advanced use cases for hardware hackers and manufacturers.
some separation at one or more levels of interfaces is needed to keep things maintainable and usable imho. OTOH i doubt this will fly soon-ish due to lack of man power anyway... hence my choice in this patch to mark the board as known-bad + comment :)