[LinuxBIOS] Random Bios Postcodes after 0x88 with 440BX

[roger]

Using a PCI Bios Postcard here and seeing some random Bios Postcodes.

clipping from LinuxBIOSv2/documentation/POSTCODES:
---snip---
0x10 Entry into protected mode
0x01 Entry into 'crt0.s' reset code jumps to here
0x11 Start copying LinuxBIOS to RAM with decompression if compressed
0x12 Copy/decompression finished jumping to RAM
0x80 Entry into LinuxBIOS in RAM
0x13 Entry into c_start
0xfe Pre call to hardwaremain()
0x39 Console is initialized
0x40 Console boot message succeeded
0x66 Devices have been enumerated
0x88 Devices have been configured
0x89 Devices have been enabled
---snip---

I don't know if the above are listed in an order that states these
postcodes should be reported on the device or any order, but I do get
the following reported on my postcard in order:

0x80, 0x88, E7
0x80, 0x88, 27
0x80, 0x88, A1, AC

(Notice the 3rd and 4th post_code reported appear random.)

Back Ground Info:
I'm using the s1826 target with a 440BX board that has a Winbond
w83977tf SuperIO chip.

So I made the following changes for supporting the SuperIO W83977EF-AW
chip.

LinuxBIOSv2/src/mainboard/tyan/s1846/auto.c
---snip---
/*#include "superio/nsc/pc87309/pc87309_early_serial.c"*/
#include "superio/winbond/w83977tf/w83977tf_early_serial.c"

/*#define SERIAL_DEV PNP_DEV(0x2e, PC87309_SP1)*/
#define SERIAL_DEV PNP_DEV(0x3f0, W83977TF_SP1)
---snip---

(w83977tf is an earlier model of the w83977ef-aw chip but appears very
similar layout, if not, the same with minor fixes or updates.)
> From what I'm guessing, superio devices are configured by the 0x88

post_code, but enabling the devices fails???

Wed Apr 25 19:26:00 PDT 2007

[roger]

On Wed, 2007-04-25 at 19:26 -0700, roger wrote:
> Using a PCI Bios Postcard here and seeing some random Bios Postcodes.
> 0x80, 0x88, E7
> 0x80, 0x88, 27
> 0x80, 0x88, A1, AC
>
> (Notice the 3rd and 4th post_code reported appear random.)
> > From what I'm guessing, superio devices are configured by the 0x88
>
> post_code, but enabling the devices fails???

Still looks like I'm getting no console output via serial port.

(...am getting serial output from linux kernel on a normal boot with
default award bios.)

Currently, I'm scanning the source trying to follow the flow it.

Wed Apr 25 19:50:06 PDT 2007

[roger]

Here's a quick patch for re-working the Tyan S1846 (440BX) tree to work
with the DFI P2BXL (440BX) but using a winbond superio.

(I noticed I forget to modify from "PC87309_SP1" to "W83977TF_SP1"
earlier.)

But still, no console and only "0x80 0x88 0xE7" series bios post_code
seems to be commonly displayed here.

Attached a quick patch for review if anybody's interested.

Wed Apr 25 23:38:18 PDT 2007

[Uwe Hermann]

On Wed, Apr 25, 2007 at 11:43:49PM -0700, roger wrote:
> Index: LinuxBIOSv2.20070425/src/mainboard/tyan/s1846/auto.c
>
> --- LinuxBIOSv2.20070425/src/mainboard/tyan/s1846/auto.c	(revision 2618)
> +++ LinuxBIOSv2.20070425/src/mainboard/tyan/s1846/auto.c	(working copy)
> @@ -34,11 +34,11 @@
>  #include "mainboard/bitworks/ims/debug.c"  // FIXME
>  #include "pc80/udelay_io.c"
>  #include "lib/delay.c"
> -#include "superio/nsc/pc87309/pc87309_early_serial.c"
> +#include "superio/winbond/w83977tf/w83977tf_early_serial.c"
>  #include "cpu/x86/mtrr/earlymtrr.c"
>  #include "cpu/x86/bist.h"
>
> -#define SERIAL_DEV PNP_DEV(0x2e, PC87309_SP1)
> +#define SERIAL_DEV PNP_DEV(0x3f0, W83977TF_SP1)

Strange, the patch looks correct. Have you tried all variations in this
line (0x2e, 0x4e, 0x3f0, 0x3f8)?

I'll see if I can find some hardware with that Super I/O here for
testing...

Uwe.

[roger]

On Fri, 2007-04-27 at 00:45 +0200, Uwe Hermann wrote:
> On Wed, Apr 25, 2007 at 11:43:49PM -0700, roger wrote:
> > Index: LinuxBIOSv2.20070425/src/mainboard/tyan/s1846/auto.c
> >
> > --- LinuxBIOSv2.20070425/src/mainboard/tyan/s1846/auto.c	(revision 2618)
> > +++ LinuxBIOSv2.20070425/src/mainboard/tyan/s1846/auto.c	(working copy)
> > @@ -34,11 +34,11 @@
> >  #include "mainboard/bitworks/ims/debug.c"  // FIXME
> >  #include "pc80/udelay_io.c"
> >  #include "lib/delay.c"
> > -#include "superio/nsc/pc87309/pc87309_early_serial.c"
> > +#include "superio/winbond/w83977tf/w83977tf_early_serial.c"
> >  #include "cpu/x86/mtrr/earlymtrr.c"
> >  #include "cpu/x86/bist.h"
> >
> > -#define SERIAL_DEV PNP_DEV(0x2e, PC87309_SP1)
> > +#define SERIAL_DEV PNP_DEV(0x3f0, W83977TF_SP1)
>
> Strange, the patch looks correct. Have you tried all variations in this
> line (0x2e, 0x4e, 0x3f0, 0x3f8)?
>
> I'll see if I can find some hardware with that Super I/O here for
> testing...

Forgive me as I haven't tried every iobase.  I figured, since my bios is
defaulting to 0x3f8, then auto.c should be fine with 0x3f8.

I did notice a lot of 0x7f8 specified in the SuperIO files.  It seems as
if the 0x7f8 is being used with PNP?  Well, I even went as far as
replacing all those with original sensible value as were listed in
LinuxBiosv1 W83977EF code.
> From looks, you or somebody ported W83977EF to W83977TF w/o bringing in

the old W83977EF files.  The EF series as the following differences:

--- Richard Smith 05SEP2003 Post ---
> > the 83977ef is supported already.
>
> What's the diff between a TF and EF?

Looking at the data sheets...

- The TF suppports 13 IRQs, the EF only 12.

- The TF has
"23 programmable general purpose I/O ports; 3 dedicate, 20 optional",
while
the EF has only
"14 programmable general purpose I/O ports; 6 dedicate, 8 optional".

Oh, and the TF is compliant wih the Microsoft PC97 Hardware Design
Guide;
the EF with the PC98 version of same. Big Deal.

Other than that, they look identical.
--- End Old Post ---

As i said in my previous email, I'm going to work on my Tyan S1832DL
(same SuperIO as the S1846).  Maybe I'm doing something wrong still too
or the bug will present itself.

Thu Apr 26 22:39:44 PDT 2007

[roger]

On Fri, 2007-04-27 at 00:45 +0200, Uwe Hermann wrote:
> On Wed, Apr 25, 2007 at 11:43:49PM -0700, roger wrote:
> > Index: LinuxBIOSv2.20070425/src/mainboard/tyan/s1846/auto.c
> >
> > --- LinuxBIOSv2.20070425/src/mainboard/tyan/s1846/auto.c	(revision 2618)
> > +++ LinuxBIOSv2.20070425/src/mainboard/tyan/s1846/auto.c	(working copy)
> > @@ -34,11 +34,11 @@
> >  #include "mainboard/bitworks/ims/debug.c"  // FIXME
> >  #include "pc80/udelay_io.c"
> >  #include "lib/delay.c"
> > -#include "superio/nsc/pc87309/pc87309_early_serial.c"
> > +#include "superio/winbond/w83977tf/w83977tf_early_serial.c"
> >  #include "cpu/x86/mtrr/earlymtrr.c"
> >  #include "cpu/x86/bist.h"
> >
> > -#define SERIAL_DEV PNP_DEV(0x2e, PC87309_SP1)
> > +#define SERIAL_DEV PNP_DEV(0x3f0, W83977TF_SP1)
>
> Strange, the patch looks correct. Have you tried all variations in this
> line (0x2e, 0x4e, 0x3f0, 0x3f8)?

I'm not sure exactly which iobase ports I haven't tried.

But I just realized.  We're not assigning a iobase to the port yet..
this is just needed for early_serial.c to get an initial console
correct?

If so, my bag.  Although 0x3f8 should work, I should really try all of
them then.

(just flashed my s1832dl with the s1846 code... If you don't hear from
me for awhile, you'll know why. ;-)

Thu Apr 26 23:35:09 PDT 2007

[roger]

On Thu, 2007-04-26 at 23:35 -0700, roger wrote:
> On Fri, 2007-04-27 at 00:45 +0200, Uwe Hermann wrote:
> > Strange, the patch looks correct. Have you tried all variations in this
> > line (0x2e, 0x4e, 0x3f0, 0x3f8)?
>
> I'm not sure exactly which iobase ports I haven't tried.
>
> But I just realized.  We're not assigning a iobase to the port yet..
> this is just needed for early_serial.c to get an initial console
> correct?
>
> If so, my bag.  Although 0x3f8 should work, I should really try all of
> them then.

Just a quick note, from the success I've just experienced with the
LinuxBiosV2 on my Tyan S1832DL board just now, console_init seems not to
be taking place at all.  The DFI P2XBL post codes go in a regular
session "0x80 > 0x88 > 0xE7 (or whatever)" and takes a span of several
seconds.  Linuxbios boots in milliseconds.  I should be seeing tons of
stuff coming out on the serial port, but nothing.

Right now, I've got both my boxes setup with Bios Saviors and a plugin
PCI Siliconkit Postcard.

Pretty flexible with which one I tackle, or both.

Fri Apr 27 00:08:26 PDT 2007

[Corey Osgood]

roger wrote:
> On Thu, 2007-04-26 at 23:35 -0700, roger wrote:
> > On Fri, 2007-04-27 at 00:45 +0200, Uwe Hermann wrote:
> > > Strange, the patch looks correct. Have you tried all variations in this
> > > line (0x2e, 0x4e, 0x3f0, 0x3f8)?
> >
> > I'm not sure exactly which iobase ports I haven't tried.
> >
> > But I just realized.  We're not assigning a iobase to the port yet..
> > this is just needed for early_serial.c to get an initial console
> > correct?
> >
> > If so, my bag.  Although 0x3f8 should work, I should really try all of
> > them then.
>
> Just a quick note, from the success I've just experienced with the
> LinuxBiosV2 on my Tyan S1832DL board just now, console_init seems not to
> be taking place at all.  The DFI P2XBL post codes go in a regular
> session "0x80 > 0x88 > 0xE7 (or whatever)" and takes a span of several
> seconds.  Linuxbios boots in milliseconds.  I should be seeing tons of
> stuff coming out on the serial port, but nothing.

Remove everything but the serial stuff (and mtrr init) from auto.c, and 
see if those post codes still appear. I suspect that port 80 is being 
used for a timer, and that's what you're seeing.

-Corey

[LinuxBIOS] W83977tf superio code (with a W83977ew chip)

[roger]

On Fri, 2007-04-27 at 03:15 -0400, Corey Osgood wrote:
> roger wrote:
> > On Thu, 2007-04-26 at 23:35 -0700, roger wrote:
> > > On Fri, 2007-04-27 at 00:45 +0200, Uwe Hermann wrote:
> > > > Strange, the patch looks correct. Have you tried all variations in this
> > > > line (0x2e, 0x4e, 0x3f0, 0x3f8)?

ok. I tried all four iobases listed above for SERIAL_DEV and nothing.
I'm going to retry and try again.  Maybe I've missed something.
> > Just a quick note, from the success I've just experienced with the
> > LinuxBiosV2 on my Tyan S1832DL board just now, console_init seems not to
> > be taking place at all.  The DFI P2XBL post codes go in a regular
> > session "0x80 > 0x88 > 0xE7 (or whatever)" and takes a span of several
> > seconds.  Linuxbios boots in milliseconds.  I should be seeing tons of
> > stuff coming out on the serial port, but nothing.
>
> Remove everything but the serial stuff (and mtrr init) from auto.c, and 
> see if those post codes still appear. I suspect that port 80 is being 
> used for a timer, and that's what you're seeing.
>
> -Corey

After removing some items from auto.c:

---Begin auto.c Snip---
    w83977tf_enable_serial(SERIAL_DEV, TTYS0_BASE);
    uart_init();
    console_init();
    print_debug("TEST1!\n");
    print_debug("TEST2!\n");

/* Halt if there was a built in self test failure. */
    report_bist_failure(bist);
    print_debug("TEST3!\n");

enable_mainboard_devices();
    print_debug("TEST4!\n");

enable_smbus();
    print_debug("TEST5!\n");

dump_spd_registers(&memctrl[0]);
/*
    sdram_initialize(sizeof(memctrl) / sizeof(memctrl[0]), memctrl);
*/

/* Check whether RAM is working.
---End auto.c Snip---

The post card usually shows only 0x80 with the above config and using
asus/p2p.  (Sometimes 0x80 then 0x12.)  sdram_initialize function seems
to be tossing a lot of random post codes into location 0x80, spawning
the usual 0xE7.  (This is a PCI based post card.)

One thing to note with this DFI P2XBL, setting "flow rts/cts" on with
ckermit was giving me problems here, but I could still get output from
this motherboard.

Anything else I can try or code I can trace?  Chip addresses?

Guessing what I really need is an oscillator for monitoring the superio
chip.  :-/

Tue May 8 15:58:53 PDT 2007

[Uwe Hermann]

On Wed, Apr 25, 2007 at 07:26:21PM -0700, roger wrote:
> I don't know if the above are listed in an order that states these
> postcodes should be reported on the device or any order, but I do get
> the following reported on my postcard in order:
>
> 0x80, 0x88, E7
> 0x80, 0x88, 27
> 0x80, 0x88, A1, AC

How does your POST card look like? Does it only display two digits or
more? Or are the above numbers meant as a series of POST codes?

(also, why 0x80 but E7 without the "0x"?)

Uwe.

[roger]

On Fri, 2007-04-27 at 00:49 +0200, Uwe Hermann wrote:
> On Wed, Apr 25, 2007 at 07:26:21PM -0700, roger wrote:
> > I don't know if the above are listed in an order that states these
> > postcodes should be reported on the device or any order, but I do get
> > the following reported on my postcard in order:
> >
> > 0x80, 0x88, E7
> > 0x80, 0x88, 27
> > 0x80, 0x88, A1, AC
>
> How does your POST card look like? Does it only display two digits or
> more? Or are the above numbers meant as a series of POST codes?

2 digits.

so...

80
88
E7

Has been the norm after specifying the interrupts and correcting the
iobase of the ttyS0 port in auto.c

My latest build, will do the following after a warm reboot and yanking
all by 1 sticking of memory:

80
88
E7
12 (or sometimes 11)

I don't know if this is progress or not.  Or even if it's just
encountering a memory bug before console init?
> (also, why 0x80 but E7 without the "0x"?)

Just denoting hex as it's coded. :-/

Just got my other Bios Savior today for my Tyan S1832DL and will give
this 440BX a try.  No need to specify the SuperIO as I've already
verified it's the same as the S1846 you've been working on.

So my S1832DL *should* give me something on serial without too much
trouble.

I'll try to start building a new tree tomorrow.

Really, I don't see why the DFI P2XBL 440bx isn't giving output as it's
been with it's SuperIO chip since LinuxBiosv1.  All I can think of it's
a bug before console init or bug with enabling early_ttyS0. :-/

Thu Apr 26 22:24:55 PDT 2007

[Uwe Hermann]

On Thu, Apr 26, 2007 at 10:34:07PM -0700, roger wrote:
> My latest build, will do the following after a warm reboot and yanking
> all by 1 sticking of memory:

Don't trust warm reboots. Always power-off and then restart, you
probably won't get reliable results otherwise.

Uwe.