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
