RE: [Etherboot-users] Re: [Etherboot-developers] TX Timeout

[Hamish G. \(M. Lists\) <ha...@dp...>]

Eric,

The way I have done the implementation caters for this - originally,
whenever the currticks() was called, the code would switch to real mode -
giving the real mode ISR's time to play, then switch back to pmode - it
would then read the BIOS memory location for the clock tick.

In my implementation, I have the interrupts running correctly in PMODE, so I
never go back into real mode and the timer is running absolutely 100%.

I have found the area of the problem, but have not yet found out what the
cause is. Basically the problem is that the PCI IO resources are not being
handled correctly somewhere.

Essentially, it appears from DEBUG info that LinuxBIOS is allocating the IO
resources correctly, but when Etherboot scans the PCI config space, the IO
addresses are not correct and I cannot for the life of me figure out why at
the moment. I have enabled a LinuxBIOS debug level of 9, so I see each
individual calls to the PCI read and writes - and these appear to be
correct, however different to the old PCI code I was using when I originally
got things running (I had used a snapshot dating back from about December or
January I think). I now see this result:

Allocating PCI resources...COMPUTE_ALLOCATE: do IO
compute_allocate_io: base 0x1000
DEVIO: Bus 0x0, devfn 0x68, reg 0x0: iosize 0x8
-->set base to 0x1000
DEVIO: Bus 0x0, devfn 0x68, reg 0x1: iosize 0x4
-->set base to 0x1010
DEVIO: Bus 0x0, devfn 0x68, reg 0x2: iosize 0x8
-->set base to 0x1020
DEVIO: Bus 0x0, devfn 0x68, reg 0x3: iosize 0x4
-->set base to 0x1030
DEVIO: Bus 0x0, devfn 0x68, reg 0x4: iosize 0x10
-->set base to 0x1040
DEVIO: Bus 0x0, devfn 0xf0, reg 0x0: iosize 0x100
-->set base to 0x1050
BUS 0: set iolimit to 0x1fff
COMPUTE_ALLOCATE: do MEM
compute_allocate_mem: base 0x80000000
DEVMEM: Bus 0x0, devfn 0x70, reg 0x0: memsize 0x1000
-->set base to 0x80000000
DEVMEM: Bus 0x0, devfn 0xf0, reg 0x1: memsize 0x1000
-->set base to 0x80001000
BUS 0: set memlimit to 0x800fffff
COMPUTE_ALLOCATE: do PREFMEM
Compute_allocate_prefmem: base 0x80100000
BUS 0: set prefmemlimit to 0x800fffff
ASSIGN RESOURCES, bus 0
Write config dword bus 0, devfn 0x68, reg 0x10, val 0x1001
Bus 0x0 devfn 0x68 reg 0x0 base to 0x1001
Write config dword bus 0, devfn 0x68, reg 0x14, val 0x1011
Bus 0x0 devfn 0x68 reg 0x1 base to 0x1011
Write config dword bus 0, devfn 0x68, reg 0x18, val 0x1021
Bus 0x0 devfn 0x68 reg 0x2 base to 0x1021
Write config dword bus 0, devfn 0x68, reg 0x1c, val 0x1031
Bus 0x0 devfn 0x68 reg 0x3 base to 0x1031
Write config dword bus 0, devfn 0x68, reg 0x20, val 0x1041
Bus 0x0 devfn 0x68 reg 0x4 base to 0x1041
Write config dword bus 0, devfn 0x70, reg 0x10, val 0x80000000
Bus 0x0 devfn 0x70 reg 0x0 base to 0x80000000
Write config dword bus 0, devfn 0xf0, reg 0x10, val 0x1051
Bus 0x0 devfn 0xf0 reg 0x0 base to 0x1051
Write config dword bus 0, devfn 0xf0, reg 0x14, val 0x80001000
Bus 0x0 devfn 0xf0 reg 0x1 base to 0x80001000

Just to let you know, devfn 0x68 is the IDE controller, 0x70 is the USB
controller and 0xf0 is the Ethernet controller.

Now after having spend about 8 hours finding out that the IDE cable on my
development plaform was screwed, I have managed to get use a root filesystm
from a hard drive so I can use lspci etc, but when the kernel boots I have
this in the PCI config space:

PCI: Allocating resources
PCI: Resource 00001000-00001007 (f=101, d=0, p=0)
PCI: Resource 00001010-00001013 (f=101, d=0, p=0)
PCI: Resource 00001020-00001027 (f=101, d=0, p=0)
PCI: Resource 00001030-00001033 (f=101, d=0, p=0)
PCI: Resource 00001040-0000104f (f=101, d=0, p=0)
PCI: Resource 80000000-80000fff (f=200, d=0, p=0)
PCI: Resource 00001000-000010ff (f=101, d=0, p=0)
<<<<<<<<<<<<<<*****************
PCI: Cannot allocate resource region 0 of device 00:1e.0
PCI: Resource 80001000-800010ff (f=200, d=0, p=0)
  got res[1400:14ff] for resource 0 of PCI device 1317:0981

Now notice that when Linux read the PCI config space, the IO region for the
ethernet controller has been detected as being 0x1000-0x10ff, and thus
overlapping with the IO region of the IDE controller. Very, very weird - I
will now go poking through the IO allocation code of LinuxBIOS and see what
is happening.

What I was finding with etherboot is that I was getting this same IO
allocation and this is obviously the reason for that not working.

Regards

Hamish

-----Original Message-----
From: eth...@li...
[mailto:eth...@li...]On Behalf Of
Eric W. Biederman
Sent: Saturday, August 04, 2001 12:19 PM
To: Etherboot users list
Cc: Etherboot Developers
Subject: Re: [Etherboot-users] Re: [Etherboot-developers] TX Timeout


ke...@us... writes:

> >Just so long as you aren't adverse to handling interrupts in etherboot
> >:)
>
> Just as long I don't have to do the testing. :-)

Not a problem...

> >Actually now that I think about it I'm curious how does etherboot
> >while in protected mode allow the BIOS to handle interrupts in real
> >mode?  Hmm. I'll have to look.
>
> Everytime it does a BIOS call it goes into real mode and interrupts get
> handled then. So this is whenever it's outputing a character, waiting
> for input, or waiting for a timeout to end.  At all other times, it's in
> protected mode and interrupts are disabled. That's why there's no code
> to set up the PM IDT.

O.k.  This may be the problem Hamish was seeing.  As we don't have
any BIOS services with linuxBIOS etherboot never even attempts
to do BIOS calls.  Though that would tent to cause timeouts to
never occur instead of having them occur to late.

I guess it could also lead to timeouts that are two short in the
ehterboot code if interrupts are disabled for multiple clock ticks.

O.k.  Time to stop and read the code.

Eric



_______________________________________________
Etherboot-developers mailing list
Eth...@li...
http://lists.sourceforge.net/lists/listinfo/etherboot-developers