Tested and works. Thanks to Carl-Daniel Hailfinger for simplifying the chipset enable for this board!
Index: board_enable.c =================================================================== --- board_enable.c (revision 1127) +++ board_enable.c (working copy) @@ -352,7 +352,9 @@ }
/** - * w83627: Enable MEMW# and set ROM size to max. + * Enable MEMW# and set ROM size to max. + * Supported chips: + * W83L517D, W83697HF/F/HG, W83697SF/UF/UG */ static void w836xx_memw_enable(uint16_t port) { @@ -1715,6 +1717,7 @@ {0x8086, 0x24D3, 0x1043, 0x80A6, 0x8086, 0x2578, 0x1043, 0x80F6, NULL, NULL, NULL, "ASUS", "P4C800-E Deluxe", 0, OK, intel_ich_gpio21_raise}, {0x8086, 0x2570, 0x1043, 0x80F2, 0x105A, 0x3373, 0x1043, 0x80F5, NULL, NULL, NULL, "ASUS", "P4P800-E Deluxe", 0, OK, intel_ich_gpio21_raise}, {0x8086, 0x2570, 0x1043, 0x80A5, 0x105A, 0x24D3, 0x1043, 0x80A6, NULL, NULL, NULL, "ASUS", "P4SD-LA", 0, NT, intel_ich_gpio32_raise}, + {0x1039, 0x0661, 0x1043, 0x8113, 0x1039, 0x0003, 0, 0, "^P4S800-MX$", NULL, NULL, "ASUS", "P4S800-MX", 512, OK, w836xx_memw_enable_2e}, {0x10B9, 0x1541, 0, 0, 0x10B9, 0x1533, 0, 0, "^P5A$", "asus", "p5a", "ASUS", "P5A", 0, OK, board_asus_p5a}, {0x10DE, 0x0030, 0x1043, 0x818a, 0x8086, 0x100E, 0x1043, 0x80EE, NULL, NULL, NULL, "ASUS", "P5ND2-SLI Deluxe", 0, OK, nvidia_mcp_gpio10_raise}, {0x8086, 0x24dd, 0x1043, 0x80a6, 0x8086, 0x2570, 0x1043, 0x8157, NULL, NULL, NULL, "ASUS", "P5PE-VM", 0, OK, intel_ich_gpio21_raise},
Signed-off-by: David Borg borg.db@gmail.com
On 28 July 2010 03:06, David Borg borg.db@gmail.com wrote:
Updated the patch to remove anything related to chip (un)locking, as there is no way to unlock the superio except by a cold reset.
Logs for the different flashrom runs and the outputs of lspci -nnvvvxxx and superiotool -deV are also attached.
w836xx_memw_enable will work for this board, however i'd still like to see the function corrected for completeness sake. I haven't yet found a datasheet for a superio in the w83627 family where the function is correct, and the supported superio's all work with sio_mask(port, 0x24, 0x28, 0x38); Perhaps it should be fixed in a separate patch?
Regards, David
On 1 July 2010 11:50, David Borg borg.db@gmail.com wrote:
Patch to add support for the Asus P4S800-MX motherboard and SIS 963 chipset. Invalidates previous patch: [PATCH] add support for SIS963
If anyone has the output of superiotool -deV for the following working boards, please forward them, so I can merge the functions w836xx_unlock_memw_enable_2e and w836xx_memw_enable_2e, and maybe fix the function w836xx_memw_enable which I believe has a typo, such that sio_mask(port, 0x24, 0x28, 0x28); becomes : sio_mask(port, 0x24, 0x28, 0x38);
Motherboards: Albatron - PM266A Pro ASUS - A7V8X-MX SE EPoX - EP-8K5A2 Shuttle - AK31 Tyan - S2498 (Tomcat K7M) Termtek - TK-3370 (Rev:2.5B) MSI - MS-6590 (KT4 Ultra) MSI - MS-6712 (KT4V) MSI - MS-7005 (651M-L)
Signed-off-by: David Borg borg.db@gmail.com
Regards, David
-- David Borg
-- David Borg
Re-sent the same patch as a file, as it lost all formatting in the text.
PS. the subsystem ID has been left blank as the PCI bridge has no subsystem ID.
On 30 July 2010 19:42, David Borg borg.db@gmail.com wrote:
Tested and works. Thanks to Carl-Daniel Hailfinger for simplifying the chipset enable for this board!
Index: board_enable.c
--- board_enable.c (revision 1127) +++ board_enable.c (working copy) @@ -352,7 +352,9 @@ }
/**
- w83627: Enable MEMW# and set ROM size to max.
- Enable MEMW# and set ROM size to max.
- Supported chips:
- W83L517D, W83697HF/F/HG, W83697SF/UF/UG
*/ static void w836xx_memw_enable(uint16_t port) { @@ -1715,6 +1717,7 @@ {0x8086, 0x24D3, 0x1043, 0x80A6, 0x8086, 0x2578, 0x1043, 0x80F6, NULL, NULL, NULL, "ASUS", "P4C800-E Deluxe", 0, OK, intel_ich_gpio21_raise}, {0x8086, 0x2570, 0x1043, 0x80F2, 0x105A, 0x3373, 0x1043, 0x80F5, NULL, NULL, NULL, "ASUS", "P4P800-E Deluxe", 0, OK, intel_ich_gpio21_raise}, {0x8086, 0x2570, 0x1043, 0x80A5, 0x105A, 0x24D3, 0x1043, 0x80A6, NULL, NULL, NULL, "ASUS", "P4SD-LA", 0, NT, intel_ich_gpio32_raise}, + {0x1039, 0x0661, 0x1043, 0x8113, 0x1039, 0x0003, 0, 0, "^P4S800-MX$", NULL, NULL, "ASUS", "P4S800-MX", 512, OK, w836xx_memw_enable_2e}, {0x10B9, 0x1541, 0, 0, 0x10B9, 0x1533, 0, 0, "^P5A$", "asus", "p5a", "ASUS", "P5A", 0, OK, board_asus_p5a}, {0x10DE, 0x0030, 0x1043, 0x818a, 0x8086, 0x100E, 0x1043, 0x80EE, NULL, NULL, NULL, "ASUS", "P5ND2-SLI Deluxe", 0, OK, nvidia_mcp_gpio10_raise}, {0x8086, 0x24dd, 0x1043, 0x80a6, 0x8086, 0x2570, 0x1043, 0x8157, NULL, NULL, NULL, "ASUS", "P5PE-VM", 0, OK, intel_ich_gpio21_raise},
Signed-off-by: David Borg borg.db@gmail.com
On 28 July 2010 03:06, David Borg borg.db@gmail.com wrote:
Updated the patch to remove anything related to chip (un)locking, as there is no way to unlock the superio except by a cold reset.
Logs for the different flashrom runs and the outputs of lspci -nnvvvxxx and superiotool -deV are also attached.
w836xx_memw_enable will work for this board, however i'd still like to see the function corrected for completeness sake. I haven't yet found a datasheet for a superio in the w83627 family where the function is correct, and the supported superio's all work with sio_mask(port, 0x24, 0x28, 0x38); Perhaps it should be fixed in a separate patch?
Regards, David
On 1 July 2010 11:50, David Borg borg.db@gmail.com wrote:
Patch to add support for the Asus P4S800-MX motherboard and SIS 963 chipset. Invalidates previous patch: [PATCH] add support for SIS963
If anyone has the output of superiotool -deV for the following working boards, please forward them, so I can merge the functions w836xx_unlock_memw_enable_2e and w836xx_memw_enable_2e, and maybe fix the function w836xx_memw_enable which I believe has a typo, such that sio_mask(port, 0x24, 0x28, 0x28); becomes : sio_mask(port, 0x24, 0x28, 0x38);
Motherboards: Albatron - PM266A Pro ASUS - A7V8X-MX SE EPoX - EP-8K5A2 Shuttle - AK31 Tyan - S2498 (Tomcat K7M) Termtek - TK-3370 (Rev:2.5B) MSI - MS-6590 (KT4 Ultra) MSI - MS-6712 (KT4V) MSI - MS-7005 (651M-L)
Signed-off-by: David Borg borg.db@gmail.com
Regards, David
-- David Borg
-- David Borg
-- David Borg
On 30.07.2010 20:17, David Borg wrote:
the subsystem ID has been left blank as the PCI bridge has no subsystem ID.
On 30 July 2010 19:42, David Borg borg.db@gmail.com wrote:
Tested and works. Thanks to Carl-Daniel Hailfinger for simplifying the chipset enable for this board!
Signed-off-by: David Borg borg.db@gmail.com
Index: board_enable.c
--- board_enable.c (revision 1127) +++ board_enable.c (working copy) @@ -352,7 +352,9 @@ }
/**
- w83627: Enable MEMW# and set ROM size to max.
- Enable MEMW# and set ROM size to max.
- Supported chips:
- W83L517D, W83697HF/F/HG, W83697SF/UF/UG
Is there a reason you removed w83627 from the list?
*/ static void w836xx_memw_enable(uint16_t port) { @@ -1715,6 +1717,7 @@ {0x8086, 0x24D3, 0x1043, 0x80A6, 0x8086, 0x2578, 0x1043, 0x80F6, NULL, NULL, NULL, "ASUS", "P4C800-E Deluxe", 0, OK, intel_ich_gpio21_raise}, {0x8086, 0x2570, 0x1043, 0x80F2, 0x105A, 0x3373, 0x1043, 0x80F5, NULL, NULL, NULL, "ASUS", "P4P800-E Deluxe", 0, OK, intel_ich_gpio21_raise}, {0x8086, 0x2570, 0x1043, 0x80A5, 0x105A, 0x24D3, 0x1043, 0x80A6, NULL, NULL, NULL, "ASUS", "P4SD-LA", 0, NT, intel_ich_gpio32_raise},
- {0x1039, 0x0661, 0x1043, 0x8113, 0x1039, 0x0003, 0, 0, "^P4S800-MX$", NULL, NULL, "ASUS", "P4S800-MX", 512, OK, w836xx_memw_enable_2e},
Second subsystem vendor has one space too few, and second subsystem device has one space too many.
{0x10B9, 0x1541, 0, 0, 0x10B9, 0x1533, 0, 0, "^P5A$", "asus", "p5a", "ASUS", "P5A", 0, OK, board_asus_p5a}, {0x10DE, 0x0030, 0x1043, 0x818a, 0x8086, 0x100E, 0x1043, 0x80EE, NULL, NULL, NULL, "ASUS", "P5ND2-SLI Deluxe", 0, OK, nvidia_mcp_gpio10_raise}, {0x8086, 0x24dd, 0x1043, 0x80a6, 0x8086, 0x2570, 0x1043, 0x8157, NULL, NULL, NULL, "ASUS", "P5PE-VM", 0, OK, intel_ich_gpio21_raise},
I'll leave the review to Michael or Uwe who know board enables really well. Apart from the cosmetic comments above, the board enable looks good IMHO. We should check if DMI matching is really needed or just excessive caution.
Regards, Carl-Daniel
Index: board_enable.c
--- board_enable.c (revision 1127) +++ board_enable.c (working copy) @@ -352,7 +352,9 @@ }
/**
- w83627: Enable MEMW# and set ROM size to max.
- Enable MEMW# and set ROM size to max.
- Supported chips:
- W83L517D, W83697HF/F/HG, W83697SF/UF/UG
Is there a reason you removed w83627 from the list?
Yes. A cross check with the datasheets for the following shows that it is not correct:
W83627DHG W83627DHG-P W83627DHG-PT W83627EEF W83627EEG W83627EHF W83627EHG W83627F W83627G W83627HF W83627HG W83627SF W83627THF W83627THG W83627UHG
In addition the function was introduced at revision 490 (http://flashrom.org/trac/flashrom/changeset/490/trunk/board_enable.c), replacing existing W83697 SuperIO enables.
Motherboards that used the function at that time where: ASUS A7V8X-MX SE and A7V400-MX, Tyan Tomcat K7M and EPoX EP-8K5A2
A7V8X-MX SE: W83697HF SuperIO (http://www.mail-archive.com/flashrom@flashrom.org/msg01316.html)
A7V400-MX: W83697HF SuperIO (http://www.mail-archive.com/linuxbios@linuxbios.org/msg05809.html Used function W83697_rom_memw_enable, and more importantly, the following CPU-Z output http://forum.darkhardware.com/viewtopic.php?f=8&t=158540)
Tomcat K7M: W83697HF SuperIO (http://tracker.coreboot.org/trac/coreboot/browser/trunk/util/flashrom/board_..., http://www.macmall.com/p/product~dpno~686101~pdp.dcjggah?source=zwb12166 - under Chipset section)
EP-8K5A2: W83697HF SuperIO (http://forums.amd.com/forum/messageview.cfm?catid=24&threadid=65550)
The following source code documentation takes care of the other motherboards /** * Winbond W83697HF Super I/O + VIA VT8235 southbridge * * Suited for: * - MSI KT4V and KT4V-L: AMD K7 + VIA KT400 + VT8235 * - MSI KT4 Ultra: AMD K7 + VIA KT400 + VT8235 */
Second subsystem vendor has one space too few, and second subsystem device has one space too many.
I'm guessing the combination of ssh + bash + nano isn't too whitespace friendly.
I'll leave the review to Michael or Uwe who know board enables really well. Apart from the cosmetic comments above, the board enable looks good IMHO. We should check if DMI matching is really needed or just excessive caution.
Ok.
Thanks for the quick review!
Regards,
David Borg
Am Sonntag, den 01.08.2010, 01:31 +0200 schrieb Carl-Daniel Hailfinger:
- {0x1039, 0x0661, 0x1043, 0x8113, 0x1039, 0x0003, 0, 0, "^P4S800-MX$", NULL, NULL, "ASUS", "P4S800-MX", 512, OK, w836xx_memw_enable_2e},
I'll leave the review to Michael or Uwe who know board enables really well. Apart from the cosmetic comments above, the board enable looks good IMHO. We should check if DMI matching is really needed or just excessive caution.
If you just have one subsystem ID, DMI might be a good idea. I suggested not to use the IDE controller for the second subsystem ID, as it varies with AHCI/RAID/whatsoever modes, but this board is so old, it has nothing of them. I suggest to use the IDE PCI ID with subsystem as second device and drop the DMI.
Regards, Michael Karcher
If you just have one subsystem ID, DMI might be a good idea. I suggested not to use the IDE controller for the second subsystem ID, as it varies with AHCI/RAID/whatsoever modes, but this board is so old, it has nothing of them. I suggest to use the IDE PCI ID with subsystem as second device and drop the DMI.
Yes in fact the only settings you can change in the bios are related to UDMA modes and such. And btw, I was wrong on iRC - all USB controllers can be disabled.
Attached patch updated as suggested & tested.
Regards, David Borg
Am Sonntag, den 01.08.2010, 22:32 +0200 schrieb David Borg:
Attached patch updated as suggested & tested.
If you add you sign-off (see http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure ), this is Acked-by: Michael Karcher flashrom@mkarcher.dialup.fu-berlin.de
I can commit it after sign-off.
Regards, Michael Karcher
Oh sorry, thought the original sign-off was enough.
Signed-off-by: David Borg borg.db@gmail.com
On 2 August 2010 09:24, Michael Karcher flashrom@mkarcher.dialup.fu-berlin.de wrote:
Am Sonntag, den 01.08.2010, 22:32 +0200 schrieb David Borg:
Attached patch updated as suggested & tested.
If you add you sign-off (see http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure ), this is Acked-by: Michael Karcher flashrom@mkarcher.dialup.fu-berlin.de
I can commit it after sign-off.
Regards, Michael Karcher
Am Montag, den 02.08.2010, 10:09 +0200 schrieb David Borg:
Oh sorry, thought the original sign-off was enough.
Signed-off-by: David Borg borg.db@gmail.com
Thanks, this is r1130 now.
Regards, Michael Karcher
On Sun, Aug 01, 2010 at 10:32:44PM +0200, David Borg wrote:
- {0x1039, 0x0661, 0x1043, 0x8113, 0x1039, 0x5513, 0x1043, 0x8087, NULL, NULL, NULL, "ASUS", "P4S800-MX", 512, OK, w836xx_memw_enable_2e},
Just for archival purposes, we talked about this on IRC. David did indeed test writing a 512KB image of random bytes to the chip on this board, so the "512" max. decode size is listed correctly here, just in case anyone is wondering when browsing the archives.
Uwe.
-
Carl-Daniel Hailfinger -
David Borg -
Michael Karcher -
Uwe Hermann