[PATCH] Add support for ASUS M2V-MX board
The way I figured this out was by picking the chip closest to the BIOS (the VT8237A southbridge) and inverting each of the GPIO lines one at a time. The GPIO stuff was gleaned from the VT8237R datasheet since I couldn't find the 'A one anywhere. All in all, a very fun and educating experience; next step, coreboot! On a related note, reading the flash back seems slightly broken; sometimes the read gets a few bytes wrong. -- David
On 30.11.2009 10:19, David Bartley wrote:
The way I figured this out was by picking the chip closest to the BIOS (the VT8237A southbridge) and inverting each of the GPIO lines one at a time. The GPIO stuff was gleaned from the VT8237R datasheet since I couldn't find the 'A one anywhere. All in all, a very fun and educating experience; next step, coreboot!
Thanks for your patch. Overall, it looks fine. Someone with VIA datasheets may want to verify. Could you please add a Signed-off-by: statement to your patch? If you reply to your own mail with the Signed-off-by: on a separate line, that is sufficient. We need this to create an audit trail of who contributed which code. Details are available at http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure
On a related note, reading the flash back seems slightly broken; sometimes the read gets a few bytes wrong.
This is very interesting. If you read a few times (without writing/erasing in between), do the results change? If not, this points to an error during writing and we should make sure that this is fixed. An error during reading is much more difficult to diagnose. Please note that latest flashrom (0.9.1-r790) has some improved write checks and should detect write errors better. If you see a pattern in the broken addresses (e.g. always the same, wandering by x bytes, common prefix, common suffix), please tell us about it as well. Regards, Carl-Daniel -- Developer quote of the month: "We are juggling too many chainsaws and flaming arrows and tigers."
On Mon, Nov 30, 2009 at 2:13 AM, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> wrote:
On 30.11.2009 10:19, David Bartley wrote:
The way I figured this out was by picking the chip closest to the BIOS (the VT8237A southbridge) and inverting each of the GPIO lines one at a time. The GPIO stuff was gleaned from the VT8237R datasheet since I couldn't find the 'A one anywhere. All in all, a very fun and educating experience; next step, coreboot!
Thanks for your patch. Overall, it looks fine. Someone with VIA datasheets may want to verify.
Could you please add a Signed-off-by: statement to your patch? If you reply to your own mail with the Signed-off-by: on a separate line, that is sufficient. We need this to create an audit trail of who contributed which code. Details are available at http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure
Done.
On a related note, reading the flash back seems slightly broken; sometimes the read gets a few bytes wrong.
This is very interesting. If you read a few times (without writing/erasing in between), do the results change? If not, this points to an error during writing and we should make sure that this is fixed. An error during reading is much more difficult to diagnose. Please note that latest flashrom (0.9.1-r790) has some improved write checks and should detect write errors better. If you see a pattern in the broken addresses (e.g. always the same, wandering by x bytes, common prefix, common suffix), please tell us about it as well.
I noticed this before I had erase/write working and can reproduce this if I reboot and try reading. I can no longer reproduce this after flashing though. -- David
On 30.11.2009 12:01, David Bartley wrote:
On Mon, Nov 30, 2009 at 2:13 AM, Carl-Daniel Hailfinger wrote:
Could you please add a Signed-off-by: statement to your patch?
Done.
Thanks.
On 30.11.2009 10:19, David Bartley wrote:
On a related note, reading the flash back seems slightly broken; sometimes the read gets a few bytes wrong.
This is very interesting. If you read a few times (without writing/erasing in between), do the results change? If not, this points to an error during writing and we should make sure that this is fixed. An error during reading is much more difficult to diagnose. Please note that latest flashrom (0.9.1-r790) has some improved write checks and should detect write errors better. If you see a pattern in the broken addresses (e.g. always the same, wandering by x bytes, common prefix, common suffix), please tell us about it as well.
I noticed this before I had erase/write working and can reproduce this if I reboot and try reading. I can no longer reproduce this after flashing though.
Ah, that. Many BIOSes out there change a few bytes in the ROM on each boot. They store boot date/time and some configuration data. Such changes are expected. As long as the readback doesn't change between subsequent reads (without any boot in between), you're in the clear. I think the flashrom wiki had some statement about this in the Random notes section. Please note that the wiki search on flashrom.org is non-functional right now. Hm. http://www.flashrom.org/Random_notes doesn't have this info. Idwer/Maciej, can one of you please add this info to the random notes page? Thanks. Regards, Carl-Daniel -- Developer quote of the month: "We are juggling too many chainsaws and flaming arrows and tigers."
On Mon, 30 Nov 2009, Carl-Daniel Hailfinger wrote:
On 30.11.2009 12:01, David Bartley wrote:
On Mon, Nov 30, 2009 at 2:13 AM, Carl-Daniel Hailfinger wrote:
On 30.11.2009 10:19, David Bartley wrote:
On a related note, reading the flash back seems slightly broken; sometimes the read gets a few bytes wrong.
This is very interesting. If you read a few times (without writing/erasing in between), do the results change? If not, this points to an error during writing and we should make sure that this is fixed. An error during reading is much more difficult to diagnose. Please note that latest flashrom (0.9.1-r790) has some improved write checks and should detect write errors better. If you see a pattern in the broken addresses (e.g. always the same, wandering by x bytes, common prefix, common suffix), please tell us about it as well.
I noticed this before I had erase/write working and can reproduce this if I reboot and try reading. I can no longer reproduce this after flashing though.
Ah, that. Many BIOSes out there change a few bytes in the ROM on each boot. They store boot date/time and some configuration data. Such changes are expected. As long as the readback doesn't change between subsequent reads (without any boot in between), you're in the clear.
I think the flashrom wiki had some statement about this in the Random notes section. Please note that the wiki search on flashrom.org is non-functional right now. Hm. http://www.flashrom.org/Random_notes doesn't have this info.
Idwer/Maciej, can one of you please add this info to the random notes page? Thanks.
Done
Regards, Carl-Daniel
Maciej -- Maciej Pijanka reg. Linux user #133161
On Mon, Nov 30, 2009 at 02:47:33PM +0100, Carl-Daniel Hailfinger wrote:
On 30.11.2009 12:01, David Bartley wrote:
On Mon, Nov 30, 2009 at 2:13 AM, Carl-Daniel Hailfinger wrote:
Could you please add a Signed-off-by: statement to your patch?
Done.
Thanks.
On 30.11.2009 10:19, David Bartley wrote:
On a related note, reading the flash back seems slightly broken; sometimes the read gets a few bytes wrong.
This is very interesting. If you read a few times (without writing/erasing in between), do the results change? If not, this points to an error during writing and we should make sure that this is fixed. An error during reading is much more difficult to diagnose. Please note that latest flashrom (0.9.1-r790) has some improved write checks and should detect write errors better. If you see a pattern in the broken addresses (e.g. always the same, wandering by x bytes, common prefix, common suffix), please tell us about it as well.
I noticed this before I had erase/write working and can reproduce this if I reboot and try reading. I can no longer reproduce this after flashing though.
Ah, that. Many BIOSes out there change a few bytes in the ROM on each boot. They store boot date/time and some configuration data. Such changes are expected. As long as the readback doesn't change between subsequent reads (without any boot in between), you're in the clear.
I think the flashrom wiki had some statement about this in the Random notes section. Please note that the wiki search on flashrom.org is non-functional right now. Hm. http://www.flashrom.org/Random_notes doesn't have this info.
Idwer/Maciej, can one of you please add this info to the random notes page? Thanks.
Regards, Carl-Daniel
My M2V-MX SE kills itself when a pci(e) card is inserted when the original image is flashed to a non-original chip. So this might be the reason. Luc Verhaegen.
On 05.12.2009 00:59, Luc Verhaegen wrote:
On Mon, Nov 30, 2009 at 02:47:33PM +0100, Carl-Daniel Hailfinger wrote:
Ah, that. Many BIOSes out there change a few bytes in the ROM on each boot. They store boot date/time and some configuration data. Such changes are expected. As long as the readback doesn't change between subsequent reads (without any boot in between), you're in the clear.
My M2V-MX SE kills itself when a pci(e) card is inserted when the original image is flashed to a non-original chip. So this might be the reason.
Yes. Some BIOSes even scream about this with a message like "ESCD update failed!". The secret is to replace the old chip with a new chip that has the same command set and the same eraseblock sizes. Regards, Carl-Daniel -- Developer quote of the month: "We are juggling too many chainsaws and flaming arrows and tigers."
Signed-off-by: David Bartley <dtbartle@csclub.uwaterloo.ca> On Mon, Nov 30, 2009 at 1:19 AM, David Bartley <dtbartle@csclub.uwaterloo.ca> wrote:
The way I figured this out was by picking the chip closest to the BIOS (the VT8237A southbridge) and inverting each of the GPIO lines one at a time. The GPIO stuff was gleaned from the VT8237R datasheet since I couldn't find the 'A one anywhere. All in all, a very fun and educating experience; next step, coreboot!
On a related note, reading the flash back seems slightly broken; sometimes the read gets a few bytes wrong.
-- David
Hi Luc, I almost committed this patch, then I found a line which you might object to. We have a lspci for exactly this board from another user. Subject: [flashrom] Asus M2V-MX information From: Michael Spang <mspang@csclub.uwaterloo.ca> On 30.11.2009 10:19, David Bartley wrote:
+ {0x1106, 0x3337, 0x1043, 0x80ed, 0x1106, 0xB188, 0, 0, NULL, NULL, "ASUS", "M2V-MX", board_asus_m2v_mx},
We might want to pick a pair of device IDs which has subsystems. Regards, Carl-Daniel -- Developer quote of the month: "We are juggling too many chainsaws and flaming arrows and tigers."
On Fri, Dec 4, 2009 at 6:41 PM, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> wrote:
Hi Luc,
I almost committed this patch, then I found a line which you might object to. We have a lspci for exactly this board from another user. Subject: [flashrom] Asus M2V-MX information From: Michael Spang <mspang@csclub.uwaterloo.ca>
On 30.11.2009 10:19, David Bartley wrote:
+ {0x1106, 0x3337, 0x1043, 0x80ed, 0x1106, 0xB188, 0, 0, NULL, NULL, "ASUS", "M2V-MX", board_asus_m2v_mx},
Hi, David developed this patch on the very board that lspci output was from. Does it differ in some way from what you expect? Michael
On 05.12.2009 00:54, Michael Spang wrote:
On Fri, Dec 4, 2009 at 6:41 PM, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> wrote:
Hi Luc,
I almost committed this patch, then I found a line which you might object to. We have a lspci for exactly this board from another user. Subject: [flashrom] Asus M2V-MX information From: Michael Spang <mspang@csclub.uwaterloo.ca>
On 30.11.2009 10:19, David Bartley wrote:
+ {0x1106, 0x3337, 0x1043, 0x80ed, 0x1106, 0xB188, 0, 0, NULL, NULL, "ASUS", "M2V-MX", board_asus_m2v_mx},
David developed this patch on the very board that lspci output was from. Does it differ in some way from what you expect?
No, it's just that subsystem IDs with 0x0 in that table trigger a "unsafe match" mechanism in flashrom and autodetection will fail. Picking a different PCI device which has (hopefully board-specific) subsystem IDs enables auto-matching. You couldn't have known that. I asked Luc to look into this because he is our expert in picking the best hopefully-unique subsystem IDs. Side note: We really need a flashrom.org upload interface which accepts lspci/flashrom/superiotool data and can extract best matches automatically. Regards, Carl-Daniel -- Developer quote of the month: "We are juggling too many chainsaws and flaming arrows and tigers."
On Sat, Dec 05, 2009 at 12:41:37AM +0100, Carl-Daniel Hailfinger wrote:
Hi Luc,
I almost committed this patch, then I found a line which you might object to. We have a lspci for exactly this board from another user. Subject: [flashrom] Asus M2V-MX information From: Michael Spang <mspang@csclub.uwaterloo.ca>
On 30.11.2009 10:19, David Bartley wrote:
+ {0x1106, 0x3337, 0x1043, 0x80ed, 0x1106, 0xB188, 0, 0, NULL, NULL, "ASUS", "M2V-MX", board_asus_m2v_mx},
We might want to pick a pair of device IDs which has subsystems.
Regards, Carl-Daniel
Strange, so the "m2v-mx" requires a board enable, while the "m2v-mx se" (which i own) doesn't? First, i have some patches here to tighten up the match table, and i intend to just go ahead and commit them after a bit of settling time. Secondly, after that, the board matching will become a lot more strict. If there is any subsystem id present, all subsystem ids will be used. If one of the four subsystem ids is not null, all nulls have to be matched by the hardware too. So the second set of subsystem ids here better be nulls for real :) Luc Verhaegen.
On Sat, Dec 05, 2009 at 12:57:22AM +0100, Luc Verhaegen wrote:
On Sat, Dec 05, 2009 at 12:41:37AM +0100, Carl-Daniel Hailfinger wrote:
Hi Luc,
I almost committed this patch, then I found a line which you might object to. We have a lspci for exactly this board from another user. Subject: [flashrom] Asus M2V-MX information From: Michael Spang <mspang@csclub.uwaterloo.ca>
On 30.11.2009 10:19, David Bartley wrote:
+ {0x1106, 0x3337, 0x1043, 0x80ed, 0x1106, 0xB188, 0, 0, NULL, NULL, "ASUS", "M2V-MX", board_asus_m2v_mx},
We might want to pick a pair of device IDs which has subsystems.
Regards, Carl-Daniel
Strange, so the "m2v-mx" requires a board enable, while the "m2v-mx se" (which i own) doesn't?
First, i have some patches here to tighten up the match table, and i intend to just go ahead and commit them after a bit of settling time.
Secondly, after that, the board matching will become a lot more strict. If there is any subsystem id present, all subsystem ids will be used. If one of the four subsystem ids is not null, all nulls have to be matched by the hardware too. So the second set of subsystem ids here better be nulls for real :)
Luc Verhaegen.
aha, MX is lpc, MX SE is spi, so vastly different boards. Luc Verhaegen.
On Mon, Nov 30, 2009 at 01:19:23AM -0800, David Bartley wrote:
The way I figured this out was by picking the chip closest to the BIOS (the VT8237A southbridge) and inverting each of the GPIO lines one at a time. The GPIO stuff was gleaned from the VT8237R datasheet since I couldn't find the 'A one anywhere. All in all, a very fun and educating experience; next step, coreboot!
On a related note, reading the flash back seems slightly broken; sometimes the read gets a few bytes wrong.
-- David
+ {0x1106, 0x3337, 0x1043, 0x80ed, 0x1106, 0xB188, 0, 0, NULL, NULL, "ASUS", "M2V-MX", board_asus_m2v_mx},
This seems to be a better match: 0x1106, 0x1336, 0x1043, 0x80ed, 0x1106, 0x3288, 0x1043, 0x8249 Luc Verhaegen.
On Mon, Dec 7, 2009 at 7:02 AM, Luc Verhaegen <libv@skynet.be> wrote:
On Mon, Nov 30, 2009 at 01:19:23AM -0800, David Bartley wrote:
The way I figured this out was by picking the chip closest to the BIOS (the VT8237A southbridge) and inverting each of the GPIO lines one at a time. The GPIO stuff was gleaned from the VT8237R datasheet since I couldn't find the 'A one anywhere. All in all, a very fun and educating experience; next step, coreboot!
On a related note, reading the flash back seems slightly broken; sometimes the read gets a few bytes wrong.
-- David
+ {0x1106, 0x3337, 0x1043, 0x80ed, 0x1106, 0xB188, 0, 0, NULL, NULL, "ASUS", "M2V-MX", board_asus_m2v_mx},
This seems to be a better match:
0x1106, 0x1336, 0x1043, 0x80ed, 0x1106, 0x3288, 0x1043, 0x8249
Confirmed this works. The code checks for the VT8237A ISA bridge in any case. -- David
On Tue, Dec 08, 2009 at 03:45:19PM -0800, David Bartley wrote:
On Mon, Dec 7, 2009 at 7:02 AM, Luc Verhaegen <libv@skynet.be> wrote:
On Mon, Nov 30, 2009 at 01:19:23AM -0800, David Bartley wrote:
The way I figured this out was by picking the chip closest to the BIOS (the VT8237A southbridge) and inverting each of the GPIO lines one at a time. The GPIO stuff was gleaned from the VT8237R datasheet since I couldn't find the 'A one anywhere. All in all, a very fun and educating experience; next step, coreboot!
On a related note, reading the flash back seems slightly broken; sometimes the read gets a few bytes wrong.
-- David
+ {0x1106, 0x3337, 0x1043, 0x80ed, 0x1106, 0xB188, 0, 0, NULL, NULL, "ASUS", "M2V-MX", board_asus_m2v_mx},
This seems to be a better match:
0x1106, 0x1336, 0x1043, 0x80ed, 0x1106, 0x3288, 0x1043, 0x8249
Confirmed this works. The code checks for the VT8237A ISA bridge in any case.
-- David
Ok, applying your patch with the above id list. Luc Verhaegen.
On Wed, Dec 09, 2009 at 08:43:00AM +0100, Luc Verhaegen wrote:
Ok, applying your patch with the above id list.
Luc Verhaegen.
-> r795. Luc Verhaegen.
participants (5)
-
Carl-Daniel Hailfinger -
David Bartley -
Luc Verhaegen -
Maciej Pijanka -
Michael Spang