Hi,
Acked-by: Uwe Hermann uwe@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.
Feel free to commit, that should probably be another thread discussing how we want to handle the "board loses MAC address" cases.
- add Intel D865GLC to print.c
"add Intel D865GLC to print.c as non-working (ICH5 with BIOS lock enable)"
- add Zotac GeForce 8200 to the list of supported boards
"ZOTAC" as per vendor website, they use that spelling pretty consistently there (you correctly used "ZOTAC" in the source code already).
- add preliminary X79 (patsburg) PCI IDs 0x1d40 was reported already as working (not archived in our pipermail?)
One of the X79 entries is marked OK, the relevant mail for that report is http://marc.info/?l=flashrom&m=130683026218257&w=2 I think, please mention that here.
- rename some chips that had gratuitous "probing" suffixes:
- SST25VF010.REMS
- SST25VF040.REMS
- M25P05.RES
- M25P10.RES
Please mention the reason / mail / URL for that here.
- fix Asus P4P800-E Deluxe detection The original board enable was added before DMI matching and used the IDs of a Promise controller as secondary PCI ID set. The controller could be disabled in the BIOS which would make the board not match. This patch uses the SMBUS controller instead and
SMBUS -> SMBus
- B("Shuttle", "FH67", 1, "http://www.shuttle.eu/products/mini-pc/sh67h3/specification/", NULL),
^^^^ I'd add "Used in the Shuttle SH67H3 barebone." (or similar) here.
And/or make the board name "FH67 (SH67H3)", but that's probably not such a good idea.
- B("Tyan", "S2912 (Thunder n3600R)", 1, "http://www.tyan.com/product_board_detail.aspx?pid=157", NULL),
^^^^ Maybe add "Tested on the S2912G2NR model (without SAS)." or similar.
Uwe.
On Thu, 1 Sep 2011 23:20:26 +0200 Uwe Hermann uwe@hermann-uwe.de wrote:
Hi,
Acked-by: Uwe Hermann uwe@hermann-uwe.de
but please see below for a review.
thanks! i would have preferred a review for one of the other quadrillion patches, but thanks for your effort :)
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.
Feel free to commit, that should probably be another thread discussing how we want to handle the "board loses MAC address" cases.
id like to add a "missing board enable" tag there anyway... a "mostly working" category might be useful for this kind of behavior. for now i think some inconsistency is great... more pressure to fix it in the future! :P
- add Zotac GeForce 8200 to the list of supported boards
"ZOTAC" as per vendor website, they use that spelling pretty consistently there (you correctly used "ZOTAC" in the source code already).
and there is the only place it matters imho, fixed anyway
- rename some chips that had gratuitous "probing" suffixes:
- SST25VF010.REMS
- SST25VF040.REMS
- M25P05.RES
- M25P10.RES
Please mention the reason / mail / URL for that here.
the reason is stated above: they are not needed :) i have added this explanation(?): some other chip names with suffixes are needed due to lack of support for multiple probe functions per chip. this is explained here: http://www.flashrom.org/pipermail/flashrom/2011-August/007597.html
- B("Shuttle", "FH67", 1, "http://www.shuttle.eu/products/mini-pc/sh67h3/specification/", NULL),
^^^^ I'd add "Used in the Shuttle SH67H3 barebone." (or similar) here.And/or make the board name "FH67 (SH67H3)", but that's probably not such a good idea.
refrained from that due to consistency reasons. the other shuttle boards are like the one i have added. something that should be changed, but not by me. :)
- B("Tyan", "S2912 (Thunder n3600R)", 1, "http://www.tyan.com/product_board_detail.aspx?pid=157", NULL),
^^^^ Maybe add "Tested on the S2912G2NR model (without SAS)." or similar.
does not justify a comment imo. we dont comment on working boards under normal circumstances in the wiki. what might be nice is a new field with the url to the report. in the commit log it is ok, but having it in the source might be better (it would not be included in normal builds). i would prefer such a link to the vendor page links actually ;)
everything else is fixed
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.
Andrew
2011/9/2 Andrew Goodbody andrew.goodbody@tadpole.com:
On 09/01/11 22:20, Uwe Hermann 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.
-1 here. This isn't a flashing issue - flashrom works exactly as intended. It's the user's job - to provide proper bios image (with predefined MAC for example)
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 :)
-
Andrew Goodbody -
Peter Lemenkov -
Stefan Tauner -
Uwe Hermann