EPIA success and problem

[SONE Takeshi]

I somehow succeeded to enable all of 256MB SDRAM at 133MHz,
and to enable video using ADLO with original VGA BIOS, on EPIA 5000.

It now boots into GRUB in less than 2 seconds. :)
(It's too fast for IDE drive to spin up, so I have to hit reset
button after cold start.)

And, now a strange thing is happening.
When I disable USE_GENERIC_ROM and enable BOOT_IDE to
boot up the Linux kernel from LinuxBIOS directly,
it hangs at "Allocating PCI resources...".
It is before these options should take effect.
What is happening??

With USE_GENERIC_ROM, memtest86 instead of ADLO as payload works fine
(several passes ran without an error, so there is no memory problem).

Before I began tweaking DRAM and video registers, I was using BOOT_IDE
to boot directly into Linux just fine.

[Adam Sulmicki]

> I somehow succeeded to enable all of 256MB SDRAM at 133MHz,
> and to enable video using ADLO with original VGA BIOS, on EPIA 5000.

cool.
> It now boots into GRUB in less than 2 seconds. :)
> (It's too fast for IDE drive to spin up, so I have to hit reset
> button after cold start.)

hmm, in rombios.c, can you try increasing ATA_WAIT_COUNT by magnitude or
two and see if it helps?

Adam Sulmicki  writes:
> > I somehow succeeded to enable all of 256MB SDRAM at 133MHz,
> > and to enable video using ADLO with original VGA BIOS, on EPIA 5000.
>
> cool.
> > It now boots into GRUB in less than 2 seconds. :)
> > (It's too fast for IDE drive to spin up, so I have to hit reset
> > button after cold start.)
>
> hmm, in rombios.c, can you try increasing ATA_WAIT_COUNT by magnitude or
> two and see if it helps?

You need to put in the code to spin on the busy bit.

See the ehterboot source for an example.

Except on out of spec hardware that always works, and making
certain the busy bit is cleared before using a drive
is required for correct operation in all cases.

Eric

[Adam Sulmicki]

> > > It now boots into GRUB in less than 2 seconds. :)
> > > (It's too fast for IDE drive to spin up, so I have to hit reset
> > > button after cold start.)
> >
> > hmm, in rombios.c, can you try increasing ATA_WAIT_COUNT by magnitude or
> > two and see if it helps?
>
> You need to put in the code to spin on the busy bit.
>
> See the ehterboot source for an example.
>
> Except on out of spec hardware that always works, and making
> certain the busy bit is cleared before using a drive
> is required for correct operation in all cases.

I think that this code is already there.

It just that this spin has an time-out option, just so that it won't hang
for some weird reason. ATA_WAIT_COUNT should increase this timeout.

Still thanks for pointer to etherboot. I'll check it out, it might give me
better ideas how to do it :-)

Adam Sulmicki  writes:
> > > > It now boots into GRUB in less than 2 seconds. :)
> > > > (It's too fast for IDE drive to spin up, so I have to hit reset
> > > > button after cold start.)
> > >
> > > hmm, in rombios.c, can you try increasing ATA_WAIT_COUNT by magnitude or
> > > two and see if it helps?
> >
> > You need to put in the code to spin on the busy bit.
> >
> > See the ehterboot source for an example.
> >
> > Except on out of spec hardware that always works, and making
> > certain the busy bit is cleared before using a drive
> > is required for correct operation in all cases.
>
> I think that this code is already there.
>
> It just that this spin has an time-out option, just so that it won't hang
> for some weird reason. ATA_WAIT_COUNT should increase this timeout.
>
> Still thanks for pointer to etherboot. I'll check it out, it might give me
> better ideas how to do it :-)

If nothing else your timeout needs to be something like 31-32 seconds
long.  The maximum specified in the latest ATA specs is either
30 or 31 seconds, plus an additional second as a fudge factor.

Also in there is code that correctly handles > 120GB drives.

Eric

[SONE Takeshi]

On Tue, May 06, 2003 at 12:13:09PM -0400, Adam Sulmicki wrote:
> > It now boots into GRUB in less than 2 seconds. :)
> > (It's too fast for IDE drive to spin up, so I have to hit reset
> > button after cold start.)
>
> hmm, in rombios.c, can you try increasing ATA_WAIT_COUNT by magnitude or
> two and see if it helps?

Tried it but no success.
I increased that value to 0xFFFFFFFF (it should be infinite :)
but nothing changed.

Also, I put some debug statement like this:

// If we found something
        sc = inb(iobase1+ATA_CB_SC);
        sn = inb(iobase1+ATA_CB_SN);

printf("A\n");
        if ( (sc == 0x55) && (sn == 0xaa) ) {
    printf("B\n");
          write_byte(ebda_seg,&EbdaData->ata.devices[device].type,ATA_TYPE_UNKNOWN);

// reset the channel
          ata_reset (device);
    printf("C\n");

// check for ATA or ATAPI
          outb(iobase1+ATA_CB_DH, slave ? ATA_CB_DH_DEV1 : ATA_CB_DH_DEV0);
          sc = inb(iobase1+ATA_CB_SC);
          sn = inb(iobase1+ATA_CB_SN);
          if ( (sc==0x01) && (sn==0x01) ) {
    printf("D\n");
            cl = inb(iobase1+ATA_CB_CL);

And the output is this:

Bochs BIOS, 1 cpu, $Revision: 1.1 $ $Date: 2002/11/25 02:07:53 $
    [BOCHS BIOS VER:1.79]
    [COMPILE DATE:May  7 2003 TIME:03:04:48]

DEVICE:0
    A

int13_harddisk: function 02, unmapped device for DL=80
    Boot from Hard Disk 0 failed
    FATAL: Could not read the boot disk

Then tried this:
        // If we found something
        sc = inb(iobase1+ATA_CB_SC);
        sn = inb(iobase1+ATA_CB_SN);

printf("sc=%x sn=%x\n", sc, sn);
        if ( (sc == 0x55) && (sn == 0xaa) ) {
          write_byte(ebda_seg,&EbdaData->ata.devices[device].type,ATA_TYPE_UNKNOWN);

And the result:

[COMPILE DATE:May  7 2003 TIME:03:17:52]

DEVICE:0
    sc=0080 sn=0080

int13_harddisk: function 02, unmapped device for DL=80

Hope this helps.

[Adam Sulmicki]

grumbe. This code should correct initalization as per ATA-3 specs.

what hard disk is this?

I have tested the code with IBM TravelStar laptop hdd's and with SAMSUNG's
hdd's.

On Wed, 7 May 2003, SONE Takeshi wrote:
> On Tue, May 06, 2003 at 12:13:09PM -0400, Adam Sulmicki wrote:
> > > It now boots into GRUB in less than 2 seconds. :)
> > > (It's too fast for IDE drive to spin up, so I have to hit reset
> > > button after cold start.)
> >
> > hmm, in rombios.c, can you try increasing ATA_WAIT_COUNT by magnitude or
> > two and see if it helps?
>
> Tried it but no success.
> I increased that value to 0xFFFFFFFF (it should be infinite :)
> but nothing changed.
>
> Also, I put some debug statement like this:
>     // If we found something
>     sc = inb(iobase1+ATA_CB_SC);
>     sn = inb(iobase1+ATA_CB_SN);
>
> printf("A\n");
>     if ( (sc == 0x55) && (sn == 0xaa) ) {
> printf("B\n");
>       write_byte(ebda_seg,&EbdaData->ata.devices[device].type,ATA_TYPE_UNKNOWN);
>
>       // reset the channel
>       ata_reset (device);
> printf("C\n");
>
>       // check for ATA or ATAPI
>       outb(iobase1+ATA_CB_DH, slave ? ATA_CB_DH_DEV1 : ATA_CB_DH_DEV0);
>       sc = inb(iobase1+ATA_CB_SC);
>       sn = inb(iobase1+ATA_CB_SN);
>       if ( (sc==0x01) && (sn==0x01) ) {
> printf("D\n");
>         cl = inb(iobase1+ATA_CB_CL);
>
> And the output is this:
> Bochs BIOS, 1 cpu, $Revision: 1.1 $ $Date: 2002/11/25 02:07:53 $
> [BOCHS BIOS VER:1.79]
> [COMPILE DATE:May  7 2003 TIME:03:04:48]
>
> DEVICE:0
> A
>
> int13_harddisk: function 02, unmapped device for DL=80
> Boot from Hard Disk 0 failed
> FATAL: Could not read the boot disk
>
> Then tried this:
>         // If we found something
>         sc = inb(iobase1+ATA_CB_SC);
>         sn = inb(iobase1+ATA_CB_SN);
> printf("sc=%x sn=%x\n", sc, sn);
>     if ( (sc == 0x55) && (sn == 0xaa) ) {
>       write_byte(ebda_seg,&EbdaData->ata.devices[device].type,ATA_TYPE_UNKNOWN);
>
>
> And the result:
> [COMPILE DATE:May  7 2003 TIME:03:17:52]
>
> DEVICE:0
> sc=0080 sn=0080
>
> int13_harddisk: function 02, unmapped device for DL=80
>
>
> Hope this helps.

[SONE Takeshi]

On Tue, May 06, 2003 at 02:39:09PM -0400, Adam Sulmicki wrote:
> grumbe. This code should correct initalization as per ATA-3 specs.
>
> what hard disk is this?

It's a 20GB drive from Fujitsu.

$ sudo hdparm -i /dev/hda

/dev/hda:

Model=FUJITSU MPG3204AT E, FwRev=80B5, SerialNo=VH01P0C02R02
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=DualPortCache, BuffSize=512kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=40031712
 IORDY=yes, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5 
 AdvancedPM=yes: disabled (255) WriteCache=enabled
 Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1:  1 2 3 4 5

I'm thinking to replace this with a 2.5" drive.
Should I avoid Fujitsu next time? :)

[Adam Sulmicki]

> > grumbe. This code should correct initalization as per ATA-3 specs.
> > what hard disk is this?
>
> It's a 20GB drive from Fujitsu.
>
> I'm thinking to replace this with a 2.5" drive.
> Should I avoid Fujitsu next time? :)

heh. dunno. It would be interesting to see why it fails. Is that b/c the
loop times out or is that b/c it does not confirm to ATA specs, or
something else.

unfortunatelly I'm at the present time busy with other things nor I have
the hardware to test.

[ron minnich]

On Tue, 6 May 2003, Adam Sulmicki wrote:
> > I'm thinking to replace this with a 2.5" drive.
> > Should I avoid Fujitsu next time? :)

just try a different drive. You need more data points.

ron

[SONE Takeshi]

On Tue, May 06, 2003 at 03:02:21PM -0400, Adam Sulmicki wrote:
> > > grumbe. This code should correct initalization as per ATA-3 specs.
> > > what hard disk is this?
> >
> > It's a 20GB drive from Fujitsu.
> >
> > I'm thinking to replace this with a 2.5" drive.
> > Should I avoid Fujitsu next time? :)
>
> heh. dunno. It would be interesting to see why it fails. Is that b/c the
> loop times out or is that b/c it does not confirm to ATA specs, or
> something else.
>
> unfortunatelly I'm at the present time busy with other things nor I have
> the hardware to test.

I inserted a call to wait_for_notbusy prior to any tests, and it worked. :)
I think this is what etherboot is doing (with appropreate timeout).
In my case, the timeout is infinite, but even if I changed it to probe
4 devices, no visible delay was observed.

(this is not a diff, cvs server seems too busy to give me a diff...)

// Disable interrupts
    outb(iobase2+ATA_CB_DC, ATA_CB_DC_HD15 | ATA_CB_DC_NIEN);

+    // Wait for device to spin up
+    ata_wait_for_notbusy(iobase1);

// Look for device
    outb(iobase1+ATA_CB_DH, slave ? ATA_CB_DH_DEV1 : ATA_CB_DH_DEV0);
    outb(iobase1+ATA_CB_SC, 0x55);

Using LILO without running VGABIOS on ADLO.

[Heechul Yun]

I've extended my serial debug patch to see entire vga text console message
(printed via int10 vgabios service routine) on the serial temrnial.

I needed this because I don't want run vgabios (due to it took several
seconds) but I want to use lilo as a boot loader. Therfore, I skipped
VGABIOS and handled int10 service to direct messages to serial console.

As a result, I can use lilo instead of etherboot without performance
degradation caused by running vgabios. I think this might be useful for
those who don't need VGA text console or have problem with running VGABIOS,
but want to use lilo or grub as a boot loader.

Regard,
Heechul.

[SONE Takeshi]

On Tue, May 06, 2003 at 07:21:05PM +0900, ts1 wrote:
> And, now a strange thing is happening.
> When I disable USE_GENERIC_ROM and enable BOOT_IDE to
> boot up the Linux kernel from LinuxBIOS directly,
> it hangs at "Allocating PCI resources...".
> It is before these options should take effect.
> What is happening??

I've found out a bit about this.
When I change MAXIMUM_CONSOLE_LOGLEVEL from 8 to 9,
the problem disappears.
Also, when GCC 2.95 is used instead of GCC 3.2,
it works ok.

It looks like very delicate bug is some where in the code.

As I said before, memtest86 does not find any RAM problem.

[ron minnich]

On Thu, 8 May 2003, SONE Takeshi wrote:
> I've found out a bit about this.
> When I change MAXIMUM_CONSOLE_LOGLEVEL from 8 to 9,
> the problem disappears.

This sounds like a timing problem.
> Also, when GCC 2.95 is used instead of GCC 3.2,
> it works ok.

not necessarily. I have had lots of trouble with via chipsets over the 
years that boiled down to race conditions in the chipset. I think you've 
hit another one.
> It looks like very delicate bug is some where in the code.

probably not a bug, but probably something we have to figure out how to 
work around.

ron

[SONE Takeshi]

On Thu, May 08, 2003 at 07:47:03AM -0600, ron minnich wrote:
> > When I change MAXIMUM_CONSOLE_LOGLEVEL from 8 to 9,
> > the problem disappears.
>
> This sounds like a timing problem.

Note that in this case DEFAULT_CONSOLE_LOGLEVEL is still 8,
so printk_spew's are compiled in but does not really print anything.
> probably not a bug, but probably something we have to figure out how to 
> work around.

Ok, it sounds like a delicate thing anyway...

[SONE Takeshi]

On Thu, May 08, 2003 at 11:01:11PM +0900, ts1 wrote:
> On Thu, May 08, 2003 at 07:47:03AM -0600, ron minnich wrote:
> > > When I change MAXIMUM_CONSOLE_LOGLEVEL from 8 to 9,
> > > the problem disappears.
> >
> > This sounds like a timing problem.
>
> Note that in this case DEFAULT_CONSOLE_LOGLEVEL is still 8,
> so printk_spew's are compiled in but does not really print anything.
> > probably not a bug, but probably something we have to figure out how to 
> > work around.
>
> Ok, it sounds like a delicate thing anyway...

I removed most of lines from my vgainit.inc (which was originally posted by 
Andrew Ip, and I modified), as far as VGA is enabled,
and the problem disappeared!

Registers 0xf8 and 0xf9 are not necessory either
(so, only 0xfb is the one to enable VGA),
but it might be safe to leave them.

Below is my current version of
src/northbridge/via/vt8601/vgainit.inc.

/* Frame buffer size in MBytes */
#ifndef SMA_SIZE
#define SMA_SIZE 8
#endif

#if SMA_SIZE==2
#define FBREG 0x90
#elif SMA_SIZE==4
#define FBREG 0xa0
#elif SMA_SIZE==8
#define FBREG 0xb0
#else
#error SMA_SIZE should be 2, 4, or 8 (MB)
#endif

CS_WRITE($0xf8, $0x22) // DRAM arbitation timer - AGP, Host
        CS_WRITE($0xf9, $0x42) // DRAM arbitation timer - VGA priority, normal
        CS_WRITE($0xfb, $FBREG) // VGA enable

[Andrew Ip]

Takeshi,
> I removed most of lines from my vgainit.inc (which was originally posted by 
> Andrew Ip, and I modified), as far as VGA is enabled,
> and the problem disappeared!
> Registers 0xf8 and 0xf9 are not necessory either
> (so, only 0xfb is the one to enable VGA),
> but it might be safe to leave them.
> Below is my current version of
> src/northbridge/via/vt8601/vgainit.inc.

Have you got vga working on EPIA???  Does it have to be with ADLO?

-Andrew

[SONE Takeshi]

On Mon, May 12, 2003 at 09:40:47PM +0800, Andrew Ip wrote:
> Takeshi,
> > I removed most of lines from my vgainit.inc (which was originally posted by 
> > Andrew Ip, and I modified), as far as VGA is enabled,
> > and the problem disappeared!
> > Registers 0xf8 and 0xf9 are not necessory either
> > (so, only 0xfb is the one to enable VGA),
> > but it might be safe to leave them.
> > Below is my current version of
> > src/northbridge/via/vt8601/vgainit.inc.
>
> Have you got vga working on EPIA???  Does it have to be with ADLO?

Yes and yes.

Basically, that vgainit.inc and this bit of code in northbridge_fixup()
was enough for running ADLO with binary VGA BIOS.
(also disable shadow ON/OFF code in loader.s)

/* Turn on shadow DRAM at 0xC0000-0xFFFFF so we can write
                 * PIRQ table, VGA BIOS, Bochs BIOS, etc. */
                printk_debug("Enabling shadow DRAM at 0xC0000-0xFFFFF: ");
                pci_write_config_byte(pcidev, 0x61, 0xff);
                pci_write_config_byte(pcidev, 0x62, 0xff);
                pci_write_config_byte(pcidev, 0x63, 0xf0);
                printk_debug("done\n");

I also changed raminit.inc to work with my 256MB PC133 DIMM,
and now improving it to detect memory (size and MA type) automatically.

[Andrew Ip]

Takeshi,
> Yes and yes.
> Basically, that vgainit.inc and this bit of code in northbridge_fixup()
> was enough for running ADLO with binary VGA BIOS.
> (also disable shadow ON/OFF code in loader.s)
>             /* Turn on shadow DRAM at 0xC0000-0xFFFFF so we can write
>              * PIRQ table, VGA BIOS, Bochs BIOS, etc. */
>             printk_debug("Enabling shadow DRAM at 0xC0000-0xFFFFF: ");
>             pci_write_config_byte(pcidev, 0x61, 0xff);
>             pci_write_config_byte(pcidev, 0x62, 0xff);
>             pci_write_config_byte(pcidev, 0x63, 0xf0);
>             printk_debug("done\n");
>
>
> I also changed raminit.inc to work with my 256MB PC133 DIMM,
> and now improving it to detect memory (size and MA type) automatically.

Sounds good.  Would you send me the entire patch so that I can check in to
the cvs?  Good job!!!

-Andrew

[ron minnich]

andrew, did you apply that patch? I just asked SONE for it again. This is 
the shadow ram patch for EPIA.

ron