Since no-one seems to have solid information as to the origins of the supposedly known brokenness of flashrom on the Asus A7N8X-E, i attach here a patch to add nforce2 support, which will hopefully fix this board.
Attached as well is some lspci info i managed to pluck off the interweb. No subsystem ids though, but a board specific enable does not seem necessary for this board.
Luc Verhaegen.
On Mon, May 25, 2009 at 02:41:06PM +0200, Luc Verhaegen wrote:
Add NForce2 chipset enable.
Thanks a lot! I tested it on an ASUS A7N8X Deluxe (rev. 2.00) and it does indeed work fine (erase/write doesn't work before the patch).
(Sidenote: the PCB says "A7N8X rev 2.00" and doesn't mention "Deluxe", but according to the websites and dmidecode it really is a Deluxe):
http://www.asus.com/product.aspx?P_ID=Uz3L1ioFuZkCI0VO http://www.asus.com/product.aspx?P_ID=wAsRYm41KTp78MFC
(I have two SATA ports and two NIC ports, which hints at the Deluxe)
dmidecode also says: Version: ASUS A7N8X2.0 Deluxe ACPI BIOS Rev 1007
This should, hopefully, fix the ASUS A7N8X-E.
I'm not so sure here. The original wiki report was done by me I think, but that was a report for some other board I had temporary access to, I guess. I'd rather not touch the ASUS A7N8X-E Deluxe status for now, until somebody has actually tested it on hardware.
However, please add the "ASUS A7N8X Deluxe" (note the missing "-E" in the name) to the known-good-without-board-enables-required list (boards_ok[]) in board_enable.c. I have verified that it works with your nforce2 patch and does _not_ require further board-enables.
While the other chipset enables for nvidia could potentially also work, this one, by not touching other bits, seems like the safest solution.
Signed-off-by Luc Verhaegen libv@skynet.be
Acked-by: Uwe Hermann uwe@hermann-uwe.de
with the changed mentioned in this mail.
Index: chipset_enable.c
--- chipset_enable.c (revision 545) +++ chipset_enable.c (working copy) @@ -769,6 +769,19 @@ return 0; }
+static int enable_flash_nvidia_nforce2(struct pci_dev *dev, const char *name) +{
- uint8_t tmp;
- pci_write_byte(dev, 0x92, 0);
- tmp = pci_read_byte(dev, 0x6d);
- tmp |= 0x01;
- pci_write_byte(dev, 0x6d, tmp);
- return 0;
Please use tabs for indentation as per coding guidelines.
+}
static int enable_flash_ck804(struct pci_dev *dev, const char *name) { uint8_t old, new; @@ -981,6 +994,7 @@ {0x8086, 0x122e, OK, "Intel", "PIIX", enable_flash_piix4}, {0x10de, 0x0050, OK, "NVIDIA", "CK804", enable_flash_ck804}, /* LPC */ {0x10de, 0x0051, OK, "NVIDIA", "CK804", enable_flash_ck804}, /* Pro */
- {0x10de, 0x0060, NT, "NVIDIA", "NForce2", enable_flash_nvidia_nforce2},
^^ Can be "OK" now, as I tested this on hardware.
Hm, and maybe change "enable_flash_nvidia_nforce2" into "enable_flash_nforce2" for brevity and consistency with enable_flash_ck804 et al... (i.e. drop the "nvidia" part).
/* Slave, should not be here, to fix known bug for A01. */ {0x10de, 0x00d3, OK, "NVIDIA", "CK804", enable_flash_ck804}, {0x10de, 0x0260, NT, "NVIDIA", "MCP51", enable_flash_ck804}, Index: board_enable.c =================================================================== --- board_enable.c (revision 546) +++ board_enable.c (working copy) @@ -784,7 +784,6 @@ const struct board_info boards_bad[] = { /* Verified non-working boards (for now). */ { "Abit", "IS-10", },
- { "ASUS", "A7N8X-E Deluxe", },
Please drop this hunk until we have a test report for that hardware.
Uwe.
On Tue, May 26, 2009 at 03:15:42AM +0200, Uwe Hermann wrote:
On Mon, May 25, 2009 at 02:41:06PM +0200, Luc Verhaegen wrote:
Add NForce2 chipset enable.
Thanks a lot! I tested it on an ASUS A7N8X Deluxe (rev. 2.00) and it does indeed work fine (erase/write doesn't work before the patch).
(Sidenote: the PCB says "A7N8X rev 2.00" and doesn't mention "Deluxe", but according to the websites and dmidecode it really is a Deluxe):
http://www.asus.com/product.aspx?P_ID=Uz3L1ioFuZkCI0VO http://www.asus.com/product.aspx?P_ID=wAsRYm41KTp78MFC
(I have two SATA ports and two NIC ports, which hints at the Deluxe)
dmidecode also says: Version: ASUS A7N8X2.0 Deluxe ACPI BIOS Rev 1007
This should, hopefully, fix the ASUS A7N8X-E.
I'm not so sure here. The original wiki report was done by me I think, but that was a report for some other board I had temporary access to, I guess. I'd rather not touch the ASUS A7N8X-E Deluxe status for now, until somebody has actually tested it on hardware.
However, please add the "ASUS A7N8X Deluxe" (note the missing "-E" in the name) to the known-good-without-board-enables-required list (boards_ok[]) in board_enable.c. I have verified that it works with your nforce2 patch and does _not_ require further board-enables.
While the other chipset enables for nvidia could potentially also work, this one, by not touching other bits, seems like the safest solution.
Signed-off-by Luc Verhaegen libv@skynet.be
Acked-by: Uwe Hermann uwe@hermann-uwe.de
with the changed mentioned in this mail.
Uwe.
Cool, thanks for testing, i guess we can change NT to OK in the chipset_enable.
About the "Bad board" list. A bad board is not like lepracy from before medicine advanced enough. When a board is added, it is not banished to some forsaken island to rot for the rest of its life. It is added to the known bad list in part to warn users and in part to spur developers on to do something about it. So we need to require an email address before adding a board to this list.
I got spurred on by this bad board listing, and did something about it. And as pointed out earlier on irc, i am certain that, if this board enable works on a standard a7n8x, it will also work on an a7n8x-e.
We don't have a solid contact here, and the problem is very certainly fixed. So we are left with a known false entry, but one that we cannot verify nonetheless.
I think the only reasonable thing to do is to: * mark the a7n8x deluxe as tested ok. * remove the a7n8x-e deluxe from the known bad list, but not add it as tested ok.
From now on, when boards are added to the known bad list, require an
email address in the commit message.
Luc Verhaegen.
On Tue, May 26, 2009 at 09:19:56AM +0200, Luc Verhaegen wrote:
Cool, thanks for testing, i guess we can change NT to OK in the chipset_enable.
Yes.
About the "Bad board" list. A bad board is not like lepracy from before medicine advanced enough. When a board is added, it is not banished to some forsaken island to rot for the rest of its life. It is added to the
Sure.
known bad list in part to warn users and in part to spur developers on to do something about it. So we need to require an email address before adding a board to this list.
It shouldn't be strictly required, though it's definately recommended, yes.
For instance, I've seen flashrom logs (-r, -wv, -E, etc) together with their output on some blogs, wikis, mailing lists etc. which are sometimes enough to tell if the board is working OK or not (e.g. requires chipset-enable or board-enable). For these external "scraped" pages we might not be able to find an email address, but it's still useful to add such a tested non-working board to our list until some user shows up in IRC/ML and helps us supporting the board.
But yes, in general, we should record who tested a certain board as OK/BAD, if possible with email address.
I think the only reasonable thing to do is to:
- mark the a7n8x deluxe as tested ok.
- remove the a7n8x-e deluxe from the known bad list, but not add it as
tested ok.
That's fine, yes. Removing it from the BAD list is ok, but we should not add it to the OK list, indeed.
Please feel free to commit.
Uwe.
On Tue, May 26, 2009 at 10:17:39AM +0200, Uwe Hermann wrote:
For instance, I've seen flashrom logs (-r, -wv, -E, etc) together with their output on some blogs, wikis, mailing lists etc. which are sometimes enough to tell if the board is working OK or not (e.g. requires chipset-enable or board-enable). For these external "scraped" pages we might not be able to find an email address, but it's still useful to add such a tested non-working board to our list until some user shows up in IRC/ML and helps us supporting the board.
Well, in that case, we should still work hard to find contact details so that they don't get lost. If the person is on irc, then you ask him for an email address. If the person is on some forum, it should often be possible to poke this person on this forum too, or at least mention the location of the report in the commit entry.
But yes, in general, we should record who tested a certain board as OK/BAD, if possible with email address.
Ok :)
I think the only reasonable thing to do is to:
- mark the a7n8x deluxe as tested ok.
- remove the a7n8x-e deluxe from the known bad list, but not add it as
tested ok.
That's fine, yes. Removing it from the BAD list is ok, but we should not add it to the OK list, indeed.
Done.
Please feel free to commit.
Ok, thanks a lot, committed as 548.
Luc Verhaegen.
On 25/05/2009, Luc Verhaegen libv@skynet.be wrote:
Since no-one seems to have solid information as to the origins of the supposedly known brokenness of flashrom on the Asus A7N8X-E, i attach here a patch to add nforce2 support, which will hopefully fix this board.
works too on K7N2, just checked erase/write/read/verify sequence,
On Tue, May 26, 2009 at 03:16:37PM +0200, Maciej Pijanka wrote:
On 25/05/2009, Luc Verhaegen libv@skynet.be wrote:
Since no-one seems to have solid information as to the origins of the supposedly known brokenness of flashrom on the Asus A7N8X-E, i attach here a patch to add nforce2 support, which will hopefully fix this board.
works too on K7N2, just checked erase/write/read/verify sequence,
Thanks, added to the 'flashrom -L' output.
Uwe.
-
Luc Verhaegen -
Maciej Pijanka -
Uwe Hermann