Linux kernel 2.6.20, PCI and hpt266

Linux kernel 2.6.20, PCI and hpt266

[Marco Braga]

[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]

Hello, I am trying to run kernel 2.6.20 on an Au1500 based board. Versions
2.4.x of the kernel are correctly working.

Problem: on the board there is a HighPoint 371N ATA controller. At the
moment the kernel 2.6.20 boots and runs, but the ATA controller does not
recognize the IDE disk.

Details:
The driver I use is "drivers/ide/pci/hpt266.c". I've already fixed the
timing problems and PLL configuration that afflict this controller, and
removed RESOURCE_64BIT to fix problems with the PCI bus on mips and
resource_size_t casts.

I've managed to follow the problem to ide-probe.c, in function
"actual_try_to_identify". It seems that the values read from the ATA
registers through IO ports are not correct. As every ATA controller, it
needs 8 bytes in IO port space for Command Block registers, and 4 bytes for
the Control Block registers. They are mapped by the kernel at:

1400-1407 (8 bytes) Command block channel 0
1408-140F (8 bytes) Command block channel 1
1410-1413 (4 bytes) Control block channel 0
1414-1417 (4 bytes) Control block channel 1

Notice that Highpoint 371N has registers for 2 channel, but the pinout for
only 1 channel. In fact the first channel is disabled by the driver, so the
actual registers are in the range 1408-140F and 1414-1417. The first sign of
the problem is that INB do not read the correct values for the ALTSTATUS
register. In fact the kernel reports:

 ... probing with STATUS(...) instead of ALTSTATUS(...)

[as in ide-probe.c, line 290]

The values read from the ATA registers are completely wrong. The registers
are accessed through hwif->INB, that are common "inb" functions. This makes
me suspect that "inX" functions are not working, but I don't know how to
test this. Notice that the PCI controller configuration space is correctly
accessed, as I can confirm reading sys/bus/pci/.../config.

Can you help or suggest me anything?
Thanx!

[-- Attachment #2: Type: text/html, Size: 2026 bytes --]

Re: Linux kernel 2.6.20, PCI and hpt266

[Sergei Shtylyov]

Hello.

Marco Braga wrote:

> Hello, I am trying to run kernel 2.6.20 on an Au1500 based board. Versions
> 2.4.x of the kernel are correctly working.

    How could they work I wonder? :-O

> Problem: on the board there is a HighPoint 371N ATA controller. At the

    There's *no* proper support for HPT371N in 2.4.x.

> moment the kernel 2.6.20 boots and runs, but the ATA controller does not
> recognize the IDE disk.

> Details:
> The driver I use is "drivers/ide/pci/hpt266.c". I've already fixed the

    I guess you mean hpt366.c. :-)

> timing problems and PLL configuration that afflict this controller, and
> removed RESOURCE_64BIT to fix problems with the PCI bus on mips and
> resource_size_t casts.

    Erm, does it indeed fix the problem I wonder?

> I've managed to follow the problem to ide-probe.c, in function
> "actual_try_to_identify". It seems that the values read from the ATA
> registers through IO ports are not correct. As every ATA controller, it
> needs 8 bytes in IO port space for Command Block registers, and 4 bytes for
> the Control Block registers. They are mapped by the kernel at:

> 1400-1407 (8 bytes) Command block channel 0
> 1408-140F (8 bytes) Command block channel 1
> 1410-1413 (4 bytes) Control block channel 0
> 1414-1417 (4 bytes) Control block channel 1

> Notice that Highpoint 371N has registers for 2 channel, but the pinout for
> only 1 channel. In fact the first channel is disabled by the driver, so the
> actual registers are in the range 1408-140F and 1414-1417. The first 
> sign of
> the problem is that INB do not read the correct values for the ALTSTATUS
> register. In fact the kernel reports:

> ... probing with STATUS(...) instead of ALTSTATUS(...)

> [as in ide-probe.c, line 290]

> The values read from the ATA registers are completely wrong. The registers
> are accessed through hwif->INB, that are common "inb" functions. This makes
> me suspect that "inX" functions are not working, but I don't know how to
> test this. Notice that the PCI controller configuration space is correctly
> accessed, as I can confirm reading sys/bus/pci/.../config.

    The PCI config. space accesses use completely different meachanism form 
I/O and memory accesses.

> Can you help or suggest me anything?

    Well, I guess I'll try the current kernel on one of my DBAu1x00 boards...

> Thanx!

WBR, Sergei

Re: Linux kernel 2.6.20, PCI and hpt266

[Marco Braga]

[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]

2007/3/5, Sergei Shtylyov <sshtylyov@ru.mvista.com>:

> Hello, I am trying to run kernel 2.6.20 on an Au1500 based board. Versions
> > 2.4.x of the kernel are correctly working.
>
>     How could they work I wonder? :-O


Eheheh :-)


> > Problem: on the board there is a HighPoint 371N ATA controller. At the
>
>     There's *no* proper support for HPT371N in 2.4.x.


We've modified them to work. We fixed the "first channel disabled" problem
and the "set pll with a wrong algorithm", etc. :-)


> Details:
> > The driver I use is "drivers/ide/pci/hpt266.c". I've already fixed the
>
>     I guess you mean hpt366.c. :-)


Whoops. Right. I'm using hpt366.c. I'd also like to try the nel libata
drivers.


> > timing problems and PLL configuration that afflict this controller, and
> > removed RESOURCE_64BIT to fix problems with the PCI bus on mips and
> > resource_size_t casts.
>
>     Erm, does it indeed fix the problem I wonder?


Well, at least this change removed the "skipping PCI config due to resource
conflict" error.


>     The PCI config. space accesses use completely different meachanism
> form
> I/O and memory accesses.


I suspected this, but sadly I am novice to PCI. Thank you very much, Sergei.

Today I've done another test: dumping I/O ATA registers, and the results are
puzzling:

The format is:

[hw->io_ports index] [I/O port addr] [I/O port value]

[17179571.588000] 0 addr: 0x1408  val: 0x08
[17179571.596000] 1 addr: 0x1409  val: 0x09
[17179571.608000] 2 addr: 0x140a  val: 0x0a
[17179571.620000] 3 addr: 0x140b  val: 0x0b
[17179571.632000] 4 addr: 0x140c  val: 0x0c
[17179571.644000] 5 addr: 0x140d  val: 0x0d
[17179571.656000] 6 addr: 0x140e  val: 0xa0
[17179571.668000] 7 addr: 0x140f  val: 0x0f
[17179571.680000] 8 addr: 0x1416  val: 0x0a
[17179571.692000] 9 addr: 0x00  val: 0x48

The values seem wrong to me..

Bye!

[-- Attachment #2: Type: text/html, Size: 3257 bytes --]

Re: Linux kernel 2.6.20, PCI and hpt266

[Marco Braga]

[-- Attachment #1: Type: text/plain, Size: 674 bytes --]

Hello,

I have a quick update on the situation. I've compiled kernel 2.6.17.14 for
the same architecture and the hard disk controller works. Moreover I've
imported the new hpt366.c driver from kernel 2.6.20 into kernel 2.6.17 and
it works perfectly, managing the "missing first channel" issue with 371N
without a problem. Still I'd like to understand where is the problem with
kernel 2.6.20. It seems to me that resource and pci mamagement has changed a
lot, sadly I'm not experienced enough to understand the exact details or
follow up the problem. My only clue here is that "inb" does not work
correctly on PCI I/O mapped registers.

Thank you for any help on this issue!

[-- Attachment #2: Type: text/html, Size: 768 bytes --]

Re: Linux kernel 2.6.20, PCI and hpt266

[Marco Braga]

[-- Attachment #1: Type: text/plain, Size: 80 bytes --]

Hello Sergei,

did you had the time to test the 2.6.20 kernel on Au1500?
Thanx!

[-- Attachment #2: Type: text/html, Size: 97 bytes --]