This patch adds code to flashrom to disable write protection on the Mitac 6513WU (Compaq OEM) Pentium 3 board. I've tested it by writing and verifying an image.
It raises WP# on the FWH via GP30 on the super I/O (SMSC LPC47U332). TBL# is hard-wired to VCC on this board.
Signed-off-by: Michael Gold mgold@ncf.ca
On Thu, Jun 18, 2009 at 04:52:13PM -0400, Michael Gold wrote:
This patch adds code to flashrom to disable write protection on the Mitac 6513WU (Compaq OEM) Pentium 3 board. I've tested it by writing and verifying an image.
It raises WP# on the FWH via GP30 on the super I/O (SMSC LPC47U332). TBL# is hard-wired to VCC on this board.
Signed-off-by: Michael Gold mgold@ncf.ca
Index: util/flashrom/board_enable.c
--- util/flashrom/board_enable.c (revision 605) +++ util/flashrom/board_enable.c (working copy) @@ -693,6 +693,73 @@ }
/**
- Find the runtime registers of an SMSC Super I/O, after verifying its
- chip ID.
- Returns the base port of the runtime register block, or 0 on error.
- */
+static uint16_t smsc_find_runtime(uint16_t sio_port, uint16_t chip_id,
uint8_t logical_device)+{
- uint16_t rt_port = 0;
- /* Verify the chip ID. */
- OUTB(0x55, sio_port); /* enable configuration */
- if (sio_read(sio_port, 0x20) != chip_id) {
fprintf(stderr, "\nERROR: SMSC super I/O not found.\n");goto out;- }
- /* If the runtime block is active, get its address. */
- sio_write(sio_port, 0x07, logical_device);
- if (sio_read(sio_port, 0x30) & 1) {
rt_port = (sio_read(sio_port, 0x60) << 8)| sio_read(sio_port, 0x61);- }
- if (rt_port == 0) {
fprintf(stderr, "\nERROR: ""Super I/O runtime interface not available.\n");- }
+out:
- OUTB(0xaa, sio_port); /* disable configuration */
- return rt_port;
+}
+/**
- Disable write protection on the Mitac 6513WU. WP# on the FWH is
- connected to GP30 on the Super I/O, and TBL# is always high.
- */
+static int board_mitac_6513wu(const char *name) +{
- struct pci_dev *dev;
- uint16_t rt_port;
- uint8_t val;
- dev = pci_dev_find(0x8086, 0x2410); /* Intel 82801AA ISA bridge */
- if (!dev) {
fprintf(stderr, "\nERROR: Intel 82801AA ISA bridge not found.\n");return -1;- }
- rt_port = smsc_find_runtime(0x4e, 0x54, 0xa);
- if (rt_port == 0)
return -1;- /* Configure the GPIO pin. */
- val = INB(rt_port + 0x33); /* GP30 config */
- val &= ~0x87; /* output, non-inverted, GPIO, push/pull */
- OUTB(val, rt_port + 0x33);
- /* Disable write protection. */
- val = INB(rt_port + 0x4d); /* GP3 values */
- val |= 0x01; /* set GP30 high */
- OUTB(val, rt_port + 0x4d);
- return 0;
+}
+/**
- We use 2 sets of IDs here, you're free to choose which is which. This
- is to provide a very high degree of certainty when matching a board on
- the basis of subsystem/card IDs. As not every vendor handles
@@ -742,6 +809,7 @@ /* Note: There are >= 2 version of the Kontron 986LCD-M/mITX! */ {0x8086, 0x27b8, 0, 0, 0, 0, 0, 0, "kontron", "986lcd-m", "Kontron", "986LCD-M", board_kontron_986lcd_m}, {0x10ec, 0x8168, 0x10ec, 0x8168, 0x104c, 0x8023, 0x104c, 0x8019, "kontron", "986lcd-m", "Kontron", "986LCD-M", board_kontron_986lcd_m},
- {0x8086, 0x2410, 0, 0, 0x8086, 0x7124, 0, 0, "mitac", "6513wu", "Mitac", "6513WU", board_mitac_6513wu}, {0x10de, 0x005e, 0, 0, 0, 0, 0, 0, "msi", "k8n-neo3", "MSI", "MS-7135 (K8N Neo3)", w83627thf_gpio4_4_raise_4e}, {0x1106, 0x3149, 0x1462, 0x7094, 0x10ec, 0x8167, 0x1462, 0x094c, NULL, NULL, "MSI", "MS-6702E (K8T Neo2-F)",w83627thf_gpio4_4_raise_2e}, {0x1106, 0x0571, 0x1462, 0x7120, 0, 0, 0, 0, "msi", "kt4v", "MSI", "MS-6712 (KT4V)", board_msi_kt4v},
You should be able to get subsystem ids for autodetection and the likelyhood of this device having actual coreboot support approaches 0. So please fill out the subsystem ids and/or provide the output of lspci -vn and remove the coreboot ids.
Luc Verhaegen.
Here's an updated patch which adds a Mitac 6513WU board enable with autodetection.
Signed-off-by: Michael Gold mgold@ncf.ca --- I've also attached the lspci output.
Why do you think coreboot support is unlikely? Is 82810E support a problem?
-- Michael
On Fri, Jun 19, 2009 at 02:13:35AM -0400, Michael Gold wrote:
I've also attached the lspci output.
Why do you think coreboot support is unlikely? Is 82810E support a problem?
-- Michael
It is a laptop, so yes, quite unlikely. On the other hand, if coreboot support gets added, you probably won't do this board specific rom access disable :)
- {0x8086, 0x2411, 0x8086, 0x2411, 0x8086, 0x7125, 0x0e11, 0xb165, NULL, NULL, "Mitac", "6513WU", board_mitac_6513wu},
From your pciids i would use:
{0x8086, 0x7125, 0x0e11, 0xb165, 0x125d, 0x1988, 0x0e11, 0xb19d
instead, as the first oen uses just a copy of the main ids. 0x0e11 is compaq.
00:01.0 0300: 8086:7125 (rev 03) (prog-if 00 [VGA controller]) Subsystem: 0e11:b165
01:05.0 0401: 125d:1988 (rev 10) Subsystem: 0e11:b19d
Can you verify this?
Apart from that:
Acked-by: Luc Verhaegen libv@skynet.be and a thumbs up on irc from both Carl-Daniel and Uwe.
Will commit as soon as this is tested.
Luc Verhaegen.
On Fri, Jun 19, 2009 at 13:05:49 +0200, Luc Verhaegen wrote:
On Fri, Jun 19, 2009 at 02:13:35AM -0400, Michael Gold wrote:
I've also attached the lspci output.
Why do you think coreboot support is unlikely? Is 82810E support a problem?
-- Michael
It is a laptop, so yes, quite unlikely. On the other hand, if coreboot support gets added, you probably won't do this board specific rom access disable :)
It's a desktop board with these chips: Intel 82810e GMCHe Intel 82801AA ICH SMSC LPC47U332 super I/O
The manual is at http://www.motherboards.org/files/manuals/78/6513WU.pdf
The 82810e isn't listed as supported on the wiki, but the 82810 is, and their datasheets appear largely identical based on a quick look. I was hoping to get coreboot running on it.
- {0x8086, 0x2411, 0x8086, 0x2411, 0x8086, 0x7125, 0x0e11, 0xb165, NULL, NULL, "Mitac", "6513WU", board_mitac_6513wu},
From your pciids i would use: {0x8086, 0x7125, 0x0e11, 0xb165, 0x125d, 0x1988, 0x0e11, 0xb19d
instead, as the first oen uses just a copy of the main ids. 0x0e11 is compaq.
I avoided the 0x125d ID because that's the onboard audio, and there's a jumper to disable it. I've now confirmed that the device disappears from lspci when that jumper is moved, so I don't think it's an appropriate device for autodetection. The other devices on bus 1 (09 and 0a) are also unusable since those are PCI cards.
00:01.0 0300: 8086:7125 (rev 03) (prog-if 00 [VGA controller]) Subsystem: 0e11:b165
01:05.0 0401: 125d:1988 (rev 10) Subsystem: 0e11:b19d
Can you verify this?
I'm not sure what you mean, but those IDs do appear in the config space for the devices when lspci's -x flag is used.
-- Michael
On Fri, Jun 19, 2009 at 07:38:43AM -0400, Michael Gold wrote:
On Fri, Jun 19, 2009 at 13:05:49 +0200, Luc Verhaegen wrote:
On Fri, Jun 19, 2009 at 02:13:35AM -0400, Michael Gold wrote:
I've also attached the lspci output.
Why do you think coreboot support is unlikely? Is 82810E support a problem?
-- Michael
It is a laptop, so yes, quite unlikely. On the other hand, if coreboot support gets added, you probably won't do this board specific rom access disable :)
It's a desktop board with these chips: Intel 82810e GMCHe Intel 82801AA ICH SMSC LPC47U332 super I/O
The manual is at http://www.motherboards.org/files/manuals/78/6513WU.pdf
The 82810e isn't listed as supported on the wiki, but the 82810 is, and their datasheets appear largely identical based on a quick look. I was hoping to get coreboot running on it.
Ah, i only know mitac as a laptop odm.
In that case, you do not want the coreboot ids because you will hopefully not set the board specific rom disable in your coreboot code.
- {0x8086, 0x2411, 0x8086, 0x2411, 0x8086, 0x7125, 0x0e11, 0xb165, NULL, NULL, "Mitac", "6513WU", board_mitac_6513wu},
From your pciids i would use: {0x8086, 0x7125, 0x0e11, 0xb165, 0x125d, 0x1988, 0x0e11, 0xb19d
instead, as the first oen uses just a copy of the main ids. 0x0e11 is compaq.
I avoided the 0x125d ID because that's the onboard audio, and there's a jumper to disable it. I've now confirmed that the device disappears from lspci when that jumper is moved, so I don't think it's an appropriate device for autodetection. The other devices on bus 1 (09 and 0a) are also unusable since those are PCI cards.
Ok, makes sense.
00:01.0 0300: 8086:7125 (rev 03) (prog-if 00 [VGA controller]) Subsystem: 0e11:b165
01:05.0 0401: 125d:1988 (rev 10) Subsystem: 0e11:b19d
Can you verify this?
I'm not sure what you mean, but those IDs do appear in the config space for the devices when lspci's -x flag is used.
-- Michael
Ok, patch going in.
Luc Verhaegen.
On Fri, Jun 19, 2009 at 01:57:21PM +0200, Luc Verhaegen wrote:
Ok, patch going in.
Luc Verhaegen.
-> r609.
Luc Verhaegen.
-
Luc Verhaegen -
Michael Gold