Flashrom -V output from Tyan S2915

[Richard W.M. Jones]

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.

[Michael Karcher]

Am Freitag, den 23.07.2010, 14:06 +0100 schrieb Richard W.M. Jones:
> 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

That's a common problem - Phoenix adds board and (in later revisions of
their flashing tools) flash-chip specific code to the ROM image. If the
image is to be written by phlash16.exe or winphlash, just cut the 1st MB
to use it with flashrom.

Please not that flashrom does not know about layouts of commercial
BIOSses and clears all information like serial numbers, MAC adresses (if
stored in the main BIOS ROM), Windows Activation certificates and event
logs when writing the new image, whereas the vendor tool knows how to
keep it.

Regards,
  Michael Karcher

[Carl-Daniel Hailfinger]

Hi Richard,

On 23.07.2010 15:06, Richard W.M. Jones wrote:
> 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.

Yes, vendors usually have image files with some additional information
attached at the end. The vendor image files I know of either have the
correct size or they can be truncated to the correct size (throw away
the end).
> Anyway, I hope this output is useful to you in some way.

Yes it is. There are some peculiarities I'd like to discuss with you,
though.
> flashrom v0.9.2-r1099 on Linux 2.6.33.6-147.fc13.x86_64 (x86_64), built with libpci 3.1.6, GCC 4.4.4 20100630 (Red Hat 4.4.4-10), little endian
> Calibrating delay loop... OS timer resolution is 999 usecs, 1406M loops per second, 10 myus = 0 us, 100 myus = 0 us, 1000 myus = 999 us, 10000 myus = 9999 us, 3996 myus = 3999 us, OK.

It is highly unusual for a halfway modern Linux system to have a timer
resolution of 1 ms. Usually the Linux kernel will use a time source
which has 10 us accuracy or better. Is this some special distribution
kernel?
> DMI string system-manufacturer: "# SMBIOS implementations newer than version 2.6 are not"
> DMI string system-product-name: "# SMBIOS implementations newer than version 2.6 are not"
> DMI string system-version: "# SMBIOS implementations newer than version 2.6 are not"
> DMI string baseboard-manufacturer: "# SMBIOS implementations newer than version 2.6 are not"
> DMI string baseboard-product-name: "# SMBIOS implementations newer than version 2.6 are not"
> DMI string baseboard-version: "# SMBIOS implementations newer than version 2.6 are not"
> DMI string chassis-type: "# SMBIOS implementations newer than version 2.6 are not"

Now this is a serious problem. Apparently dmidecode in Fedora has a
patch in the RPM (dmidecode-warn-on-unsupported-smbios-version.patch)
which breaks the original documented output format. If this only
affected the board enables, it wouldn't be that bad (failing/corrupting
writes on a few dozen boards which can be fixed interactively), but it
also completely disables laptop detection and that means Fedora will get
bug reports about hard lockups and/or disabled fans on laptops.
I don't want to blame Fedora because this is a patch hand-picked from
upstream dmidecode. We'll add a workaorund to flashrom ASAP.

Regards,
Carl-Daniel

[Richard W.M. Jones]

On Fri, Jul 23, 2010 at 03:42:42PM +0200, Michael Karcher wrote:
> Am Freitag, den 23.07.2010, 14:06 +0100 schrieb Richard W.M. Jones:
> > 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
>
> That's a common problem - Phoenix adds board and (in later revisions of
> their flashing tools) flash-chip specific code to the ROM image. If the
> image is to be written by phlash16.exe or winphlash, just cut the 1st MB
> to use it with flashrom.

That worked.  Maybe it should be a FAQ?  I didn't find anything about
phlash16 ROM -> bin conversion even through I did extensive searching.

Thanks,

Rich.

[Richard W.M. Jones]

On Fri, Jul 23, 2010 at 04:02:59PM +0200, Carl-Daniel Hailfinger wrote:
> On 23.07.2010 15:06, Richard W.M. Jones wrote:
> > flashrom v0.9.2-r1099 on Linux 2.6.33.6-147.fc13.x86_64 (x86_64), built with libpci 3.1.6, GCC 4.4.4 20100630 (Red Hat 4.4.4-10), little endian
> > Calibrating delay loop... OS timer resolution is 999 usecs, 1406M loops per second, 10 myus = 0 us, 100 myus = 0 us, 1000 myus = 999 us, 10000 myus = 9999 us, 3996 myus = 3999 us, OK.
>
> It is highly unusual for a halfway modern Linux system to have a timer
> resolution of 1 ms. Usually the Linux kernel will use a time source
> which has 10 us accuracy or better. Is this some special distribution
> kernel?

It's Fedora 13's standard kernel:

Linux amd.home.annexia.org 2.6.33.6-147.fc13.x86_64 #1 SMP Tue Jul 6 22:32:17 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

I've attached the boot messages.
> > DMI string system-manufacturer: "# SMBIOS implementations newer than version 2.6 are not"
> > DMI string system-product-name: "# SMBIOS implementations newer than version 2.6 are not"
> > DMI string system-version: "# SMBIOS implementations newer than version 2.6 are not"
> > DMI string baseboard-manufacturer: "# SMBIOS implementations newer than version 2.6 are not"
> > DMI string baseboard-product-name: "# SMBIOS implementations newer than version 2.6 are not"
> > DMI string baseboard-version: "# SMBIOS implementations newer than version 2.6 are not"
> > DMI string chassis-type: "# SMBIOS implementations newer than version 2.6 are not"
>
> Now this is a serious problem. Apparently dmidecode in Fedora has a
> patch in the RPM (dmidecode-warn-on-unsupported-smbios-version.patch)
> which breaks the original documented output format. If this only
> affected the board enables, it wouldn't be that bad (failing/corrupting
> writes on a few dozen boards which can be fixed interactively), but it
> also completely disables laptop detection and that means Fedora will get
> bug reports about hard lockups and/or disabled fans on laptops.
> I don't want to blame Fedora because this is a patch hand-picked from
> upstream dmidecode. We'll add a workaorund to flashrom ASAP.

Nice ...

CC-ing the dmidecode maintainer in Fedora.

Rich.

[Richard W.M. Jones]

FYI I opened a bug against Fedora:

https://bugzilla.redhat.com/show_bug.cgi?id=617621

Rich.

[PATCH] Add dmidecode quirk workaround

[Michael Karcher]

dmidecode emits a warning message about unsupported SMBIOS versions
to stdout before the information asked for when using "-s". I consider
this behaviour broken, but we still need to workaround it as e.g. Fedora
currently distributes an dmidecode with this behaviour.

Signed-off-by: Michael Karcher 
---
 dmi.c |   24 ++++++++++++++++--------
 1 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/dmi.c b/dmi.c
index cf459ec..98d595c 100644
--- a/dmi.c
+++ b/dmi.c
@@ -76,15 +76,23 @@ static char *get_dmi_string(const char *string_name)
    	msg_perr("DMI pipe open error\n");
    	return NULL;
    }
-	if (!fgets(answerbuf, DMI_MAX_ANSWER_LEN, dmidecode_pipe)) {
-		if(ferror(dmidecode_pipe)) {
-			msg_perr("DMI pipe read error\n");
-			pclose(dmidecode_pipe);
-			return NULL;
-		} else {
-			answerbuf[0] = 0;	/* Hit EOF */
+
+	/* Kill lines starting with '#', as recent dmidecode versions
+	   have the quirk to emit a "# SMBIOS implementations newer..."
+	   message even on "-s", when it *should* only print the
+	   requested string. */
+	do {
+		if (!fgets(answerbuf, DMI_MAX_ANSWER_LEN, dmidecode_pipe)) {
+			if(ferror(dmidecode_pipe)) {
+				msg_perr("DMI pipe read error\n");
+				pclose(dmidecode_pipe);
+				return NULL;
+			} else {
+				answerbuf[0] = 0;	/* Hit EOF */
+			}
    	}
-	}
+	} while(answerbuf[0] == '#');
+
    /* Toss all output above DMI_MAX_ANSWER_LEN away to prevent
       deadlock on pclose. */
    while (!feof(dmidecode_pipe))

[Anton Arapov]

On Fri, 2010-07-23 at 15:43 +0100, Richard W.M. Jones wrote:
> On Fri, Jul 23, 2010 at 04:02:59PM +0200, Carl-Daniel Hailfinger wrote:
> > On 23.07.2010 15:06, Richard W.M. Jones wrote:
> > > flashrom v0.9.2-r1099 on Linux 2.6.33.6-147.fc13.x86_64 (x86_64), built with libpci 3.1.6, GCC 4.4.4 20100630 (Red Hat 4.4.4-10), little endian
> > > Calibrating delay loop... OS timer resolution is 999 usecs, 1406M loops per second, 10 myus = 0 us, 100 myus = 0 us, 1000 myus = 999 us, 10000 myus = 9999 us, 3996 myus = 3999 us, OK.
> >
> > It is highly unusual for a halfway modern Linux system to have a timer
> > resolution of 1 ms. Usually the Linux kernel will use a time source
> > which has 10 us accuracy or better. Is this some special distribution
> > kernel?
>
> It's Fedora 13's standard kernel:
>
> Linux amd.home.annexia.org 2.6.33.6-147.fc13.x86_64 #1 SMP Tue Jul 6 22:32:17 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
>
> I've attached the boot messages.
> > > DMI string system-manufacturer: "# SMBIOS implementations newer than version 2.6 are not"
> > > DMI string system-product-name: "# SMBIOS implementations newer than version 2.6 are not"
> > > DMI string system-version: "# SMBIOS implementations newer than version 2.6 are not"
> > > DMI string baseboard-manufacturer: "# SMBIOS implementations newer than version 2.6 are not"
> > > DMI string baseboard-product-name: "# SMBIOS implementations newer than version 2.6 are not"
> > > DMI string baseboard-version: "# SMBIOS implementations newer than version 2.6 are not"
> > > DMI string chassis-type: "# SMBIOS implementations newer than version 2.6 are not"
> >
> > Now this is a serious problem. Apparently dmidecode in Fedora has a
> > patch in the RPM (dmidecode-warn-on-unsupported-smbios-version.patch)
> > which breaks the original documented output format. If this only
> > affected the board enables, it wouldn't be that bad (failing/corrupting
> > writes on a few dozen boards which can be fixed interactively), but it
> > also completely disables laptop detection and that means Fedora will get
> > bug reports about hard lockups and/or disabled fans on laptops.
> > I don't want to blame Fedora because this is a patch hand-picked from
> > upstream dmidecode. We'll add a workaorund to flashrom ASAP.
>
> Nice ...
>
> CC-ing the dmidecode maintainer in Fedora.

Thanks for putting me in copy. I will update the dmidecode to
understand the new specification and take a look at the mentioned patch
to figure out how to handle the situation better.

thanks!
Anton.
> Rich.