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.  :-/


--
Roger
http://www.eskimo.com/~roger/index.html
Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61

Tue May 8 15:58:53 PDT 2007


-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Reply via email to