[flashrom] [PATCH] Add a bunch of new/tested stuff and various small changes 7

[Stefan Tauner]

On Fri, 02 Sep 2011 11:48:10 +0100
Andrew Goodbody <andrew.goodbody at tadpole.com> wrote:

> On 09/01/11 22:20, Uwe Hermann wrote:
> > Hi,
> >
> > Acked-by: Uwe Hermann<uwe at 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 :)
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner