If the system has an SMSC LPC47N217N SuperIO, enter_conf_mode_ite()
enters configuration mode, and then exit_conf_mode_ite() kills power to
the serial UART.
I don't know if there is a proper way to detect what kind of SuperIO the
system has, but probe_superio_ite() is unsafe in its current form.
Signed-off-by: Ed Swierk <eswierk(a)aristanetworks.com>
---
Index: flashrom-0.9.2-r1057/internal.c
===================================================================
--- flashrom-0.9.2-r1057.orig/internal.c
+++ flashrom-0.9.2-r1057/internal.c
@@ -104,7 +104,10 @@ struct superio superio = {};
void probe_superio(void)
{
+#if 0
+ /* ITE probe causes SMSC LPC47N217 to power off the serial UART! */
superio = probe_superio_ite();
+#endif
#if 0
/* Winbond Super I/O code is not yet available. */
if (superio.vendor == SUPERIO_VENDOR_NONE)
It still doesn't work for me. The ROM image supplied by Tyan is
larger than 1MB and flashrom reports:
Error: Image size doesn't match
Presumably there is some sort of header in the image file.
Anyway, I hope this output is useful to you in some way.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
Hi Darmawan,
nice to see you're back.
flashrom has its own mailing list and I added it to CC.
On 15.06.2010 21:56, Darmawan Salihun wrote:
> Sorry, I haven't been able to update Winflashrom for more than 3 years now.
> I'm planning to add Windows 7 support next month.
>
Nice!
> Therefore, I'm looking for suggestions.
>
> A bit of Winflashrom background of the currently available Winflashrom
> (at flashrom.org):
>
> The programming model:
> a. User mode application:
> - Mostly "pure" flashrom source code recompiled with MinGW.
>
Current flashrom can be compiled with MinGW and Cygwin, but it doesn't
support any PCI accesses (USB and serial work).
> - libpci recompiled with MinGW (for PCI access logic). This is
> required because
> the PCI access functions in the Windows API is not guaranteed
> (marked as obsolete),
> in Windows XP SP2 and Windows 2003 server back then.
>
If the PCI access functions are still available in Windows 7, can we
simply ignore the "deprecated" warnings? CF8/CFC accesses from userspace
are not atomic and might cause mixed up PCI accesses.
> b. Device driver:
> - Provides POSIX mmap() implementation in the kernel, i.e.
> provides an entrypoint for mmap() function to user mode application.
>
Please note that we need two types of memory mapping:
sys_physmap_ro_cached() and sys_physmap_rw_uncached(). For example, the
low memory mapping for coreboot tables uses the readonly cached variant,
and any future DMI string access will also use the readonly cached
variant. Any MMIO areas (including flash access) use the uncached rw
variant. Some operating systems do not care at all about cached/uncached
mapping (they simply use the default caching settings of that memory
region), and for those you can use the uncached rw access for both
access types.
> - Provides direct I/O port access for libpci.
>
> Well, the reason for these programming model is to reduce the burden
> when moving to newer flash chip support because this programming model
> "preserves" the POSIX API in the user mode application (the device
> driver is generic enough).
> Therefore, "only" the user mode application need to be recompiled to
> support new flash chip.
>
> Any suggestions on what to change from the current programming model?
>
Current flashrom already supports PCI device flashing and onboard
flashing on DOS, Linux, FreeBSD, NetBSD, DragonFlyBSD, OpenSolaris, Mac
OS X and a few others.
Please take a look at hwaccess.c and hwaccess.h and physmap.c for things
you might want to change for Windows PCI support.
I expect Windows support in flashrom to need ~60 lines of code, maybe
less. The device driver (and libpci support) is a different question,
though.
If you have to modify any file except hwaccess.c, hwaccess.h, physmap.c
or Makefile please tell us.
If you have any questions, feel free to ask at flashrom(a)flashrom.org or
in #flashrom on irc.freenode.net.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
Reversed-engineered board enable for the ASUS A8N-LA. IDs are ISA and SMBus.
Added dmi string to match 3 HP boards: Nagami, Nagami2, Nagami2L.
Signed-off-by: Sean Nelson <audiohacked(a)gmail.com>
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(a)gmail.com>
On 28 July 2010 03:06, David Borg <borg.db(a)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(a)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(a)gmail.com>
>>
>> Regards,
>> David
>
>
>
> --
> David Borg
--
David Borg
Signed-off-by: Paul Menzel <paulepanter(a)users.sourceforge.net>
---
nicnatsemi.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/nicnatsemi.c b/nicnatsemi.c
index 1878f51..5f44677 100644
--- a/nicnatsemi.c
+++ b/nicnatsemi.c
@@ -60,7 +60,7 @@ void nicnatsemi_chip_writeb(uint8_t val, chipaddr addr)
/*
* The datasheet requires 32 bit accesses to this register, but it seems
* that requirement might only apply if the register is memory mapped.
- * Bit 8-31 of this register are apparently don't care, and if this
+ * Bit 8-31 of this register apparently don't care, and if this
* register is I/O port mapped 8 bit accesses to the lowest byte of the
* register seem to work fine. Due to that, we ignore the advice in the
* data sheet.
@@ -74,7 +74,7 @@ uint8_t nicnatsemi_chip_readb(const chipaddr addr)
/*
* The datasheet requires 32 bit accesses to this register, but it seems
* that requirement might only apply if the register is memory mapped.
- * Bit 8-31 of this register are apparently don't care, and if this
+ * Bit 8-31 of this register apparently don't care, and if this
* register is I/O port mapped 8 bit accesses to the lowest byte of the
* register seem to work fine. Due to that, we ignore the advice in the
* data sheet.
--
1.7.1
hi
I don't know is you still need info on this type of motherboard but here
are the logs from my successful attempt to flash my BIOS with you
software
Kasper M. Nielsen