Patchwork Add support for ASUS M2V-MX board

login
register
about
Submitter David Bartley
Date 2009-11-30 09:19:23
Message ID <e77a196d0911300119qbb7a358mbd92e4bb6b58d6a2@mail.gmail.com>
Download mbox | patch
Permalink /patch/616/
State Accepted
Commit r795
Headers show

Comments

David Bartley - 2009-11-30 09:19:23
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
Carl-Daniel Hailfinger - 2009-11-30 10:13:26
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
David Bartley - 2009-11-30 10:50:27
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
>
David Bartley - 2009-11-30 11:01:21
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
Carl-Daniel Hailfinger - 2009-11-30 13:47:33
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
Maciej Pijanka - 2009-11-30 14:53:17
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
Carl-Daniel Hailfinger - 2009-12-04 23:41:37
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
Michael Spang - 2009-12-04 23:54:23
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
Luc Verhaegen - 2009-12-04 23:57:22
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.
Luc Verhaegen - 2009-12-04 23:59:44
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.
Luc Verhaegen - 2009-12-05 00:05:46
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.
Carl-Daniel Hailfinger - 2009-12-05 00:10:45
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
Carl-Daniel Hailfinger - 2009-12-05 00:28:06
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
Luc Verhaegen - 2009-12-07 15:02:53
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.
David Bartley - 2009-12-08 23:45:19
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
Luc Verhaegen - 2009-12-09 07:43:00
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.
Luc Verhaegen - 2009-12-09 07:58:58
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.

Patch

Index: board_enable.c
===================================================================
--- board_enable.c	(revision 790)
+++ board_enable.c	(working copy)
@@ -180,7 +180,7 @@ 
 static void vt823x_gpio_set(struct pci_dev *dev, uint8_t gpio, int raise)
 {
 	uint16_t base;
-	uint8_t val, bit;
+	uint8_t val, bit, offset;
 
 	if ((gpio >= 12) && (gpio <= 15)) {
 		/* GPIO12-15 -> output */
@@ -192,24 +192,28 @@ 
 		val = pci_read_byte(dev, 0xE4);
 		val |= 0x20;
 		pci_write_byte(dev, 0xE4, val);
+	} else if (gpio == 5) {
+		val = pci_read_byte(dev, 0xE4);
+		val |= 0x01;
+		pci_write_byte(dev, 0xE4, val);
 	} else {
 		fprintf(stderr, "\nERROR: "
 			"VT823x GPIO%02d is not implemented.\n", gpio);
 		return;
 	}
 
-	/* Now raise/drop the GPIO line itself. */
-	bit = 0x01 << (gpio - 8);
-
 	/* We need the I/O Base Address for this board's flash enable. */
 	base = pci_read_word(dev, 0x88) & 0xff80;
 
-	val = INB(base + 0x4D);
+	offset = 0x4C + gpio / 8;
+	bit = 0x01 << (gpio % 8);
+
+	val = INB(base + offset);
 	if (raise)
 		val |= bit;
 	else
 		val &= ~bit;
-	OUTB(val, base + 0x4D);
+	OUTB(val, base + offset);
 }
 
 /**
@@ -1109,6 +1113,26 @@ 
 }
 
 /**
+ * Suited for Asus M2V-MX: VIA K8M890 + VT8237A + IT8716F
+ */
+static int board_asus_m2v_mx(const char *name)
+{
+	struct pci_dev *dev;
+
+	dev = pci_dev_find(0x1106, 0x3337);	/* VT8237A ISA bridge */
+	if (!dev) {
+		fprintf(stderr, "\nERROR: VT8237A ISA bridge not found.\n");
+		return -1;
+	}
+
+	/* GPO5 is connected to WP# and TBL#. */
+	vt823x_gpio_set(dev, 5, 1);
+
+	return 0;
+}
+
+
+/**
  * Below is the list of boards which need a special "board enable" code in
  * flashrom before their ROM chip can be accessed/written to.
  *
@@ -1148,6 +1172,7 @@ 
 	{0x1106, 0x3189, 0x1043, 0x807F,  0x1106, 0x3065, 0x1043, 0x80ED, NULL,         NULL,          "ASUS",        "A7V600-X",           board_asus_a7v600x},
 	{0x1106, 0x3189, 0x1043, 0x807F,  0x1106, 0x3177, 0x1043, 0x808C, NULL,         NULL,          "ASUS",        "A7V8X",              board_asus_a7v8x},
 	{0x1106, 0x3177, 0x1043, 0x80A1,  0x1106, 0x3205, 0x1043, 0x8118, NULL,         NULL,          "ASUS",        "A7V8X-MX SE",        board_asus_a7v8x_mx},
+	{0x1106, 0x3337, 0x1043, 0x80ed,  0x1106, 0xB188,      0,      0, NULL,         NULL,          "ASUS",        "M2V-MX",             board_asus_m2v_mx},
 	{0x8086, 0x1a30, 0x1043, 0x8070,  0x8086, 0x244b, 0x1043, 0x8028, NULL,         NULL,          "ASUS",        "P4B266",             intel_ich_gpio22_raise},
 	{0x8086, 0x1A30, 0x1043, 0x8025,  0x8086, 0x244B, 0x104D, 0x80F0, NULL,         NULL,          "ASUS",        "P4B266-LM",          intel_ich_gpio21_raise},
 	{0x8086, 0x2570, 0x1043, 0x80F2,  0x105A, 0x3373, 0x1043, 0x80F5, NULL,         NULL,          "ASUS",        "P4P800-E Deluxe",    intel_ich_gpio21_raise},