RE: eata.c module and PCI setup problem (RAID SCSI card)
Inside the driver I consistently use the address
from pci_resource_start(dev, 0) + PCI_BASE_ADDRESS_0.
That's the origin of the 0x10 offset in the io_port compared to
the resource start value.
Apart from this I see your point and it is basically correct.
I'm thinking about using inb() in read_pio as an
alternative to the
*p = le16_to_cpu(inw(iobase));
which would be a nop on i386 and byte swap halfwords
on PPC.
Once the config structure is read consistently (i.e. cleaned
from the endianess problem introduced by inw)
the H2DEV, DEV2H etc take care ov the endianess in a
portable way. Let's see if the driver works first.
-db
-----Original Message-----
From: Michel Lanners
To: Ballabio_Dario@emc.com
Cc: ad.l@delvaux.net; debian-powerpc@lists.debian.org
Sent: 09/06/02 17.16
Subject: Re: eata.c module and PCI setup problem (RAID SCSI card)
Hi Ballabio,
On 9 Jun, this message from Ballabio_Dario@emc.com echoed through
cyberspace:
> If lspci reports I/O address 0x1400 you must use io_port=0x1410,
> the additional 0x10 is the io_base_address_0 offset.
Are you sure that this is the reason for the offset? io_base_address_0
is at offset 0x10 _in_config_space_, while we're talking here of
_io_space_. I'd rather think this is a (device-spcific) offset in the
device's IO region that happens to be 0x10 in this case.
> With this value both the auto detection and the io_port option
> would give the same (good) behavior.
> The real problem is that the driver expects the "EATA" signature
> (big endian) while you get "AEAT". It looks like you have a 16 bit
> system.
No, no, this is not about a 16- or 32-bit-system. This is about the way
the data is read from the device.
Looking at the struct eata_info that you are reading from the device,
this looks to me like a stream of bytes of varying size. But you are
reading it in 16-bit quantities over a byte-swapping barrier: PCI is
little-endian, powerpc is big-endian. Therefore all data transfers going
to/coming from the PCI bus are byte-swapped.
The solution here is to not byteswap the data that you are reading from
the device, so that the byte stream that you are reading keeps the right
byte alignment.
To the debian-powerpc list: what is the correct replacement for inw()
that doesn't do byteswap?
> The driver knows that the EATA protocol mandates big endian
> and uses the cpu_to_be32 and cpu_to_be16 for host to dev conversion.
> It uses be32_to_cpu and be16_to_cpu for device to host conversion.
Not for reading the signature. That uses read_pio() which calls inw().
Therefore, your swapped signature for big-endian is not working: we're
not in the presence of a byte-swapped 32-bit quantity (your
EATA_SIG_BE), but a concatenation of two byte-swapped 16-bit quantities
(because you're reading with inw, which reads 16 bits at a time).
> You can try to use the correct conversion routines for your system
> by setting correctly the H2DEV, H2DEVS, DEV2H, DEV2HS macros
> (refer to the last source I sent).
They are probably OK (though I could be wrong...). Antoine should try
the hack I sent him for changing read_pio, and we should work on from
these results.
Cheers
Michel
> -----Original Message-----
> From: Antoine Delvaux
> To: mlan@cpu.lu
> Cc: Ballabio_Dario@emc.com
> Sent: 09/06/02 8.20
> Subject: Re: eata.c module and PCI setup problem (RAID SCSI card)
>
> Hello Michel and Ballabio,
>
> I've integrated the few debug changes from Michel and new Ballabio's
> code. Here are a few answers and description of what is happening
now.
> But I want to already thank you for your support so far.
>
>>> And here is the output when doing 'insmod eata.o' alone :
>
> I now have the following :
>
> Jun 9 13:10:21 brocoli kernel: eata.c: checking PCI ports.
> Jun 9 13:10:21 brocoli kernel: EATA: detect, seq. 0, bus 0, devfn
0x78,
> addr 0x1400.
> Jun 9 13:10:21 brocoli kernel: eata.c: no more matching PCI device.
> Jun 9 13:10:21 brocoli kernel: EATA0: signature 0x41454154 discarded.
>
> And then nothing more, no bad IN's (should this be consider good or
> strange ?) and the card hangs with the two exterior leds lit up. When
> doing lspci -vv I still have
>
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
>
> So the card is well enabled.
>
> The last log line is coming from the port_detect function when
checking
> the EATA signature. What is this signature and why is it wrong ?
>
> And with 'insmod eata.o io_port=0x1400' :
>
> Jun 9 13:41:00 brocoli kernel: eata.c: io_port modified by module
> options.
> Jun 9 13:41:00 brocoli kernel: eata.c: setup_done is set; skipping
PCI
> probe.
> Jun 9 13:41:00 brocoli kernel: EATA: enable_pci_ports, bus 0, devfn
> 0x78.
> Jun 9 13:41:00 brocoli kernel: PCI: Enabling device 00:0f.0 (0014 ->
> 0015)
>
> lspci -vv shows the same (I/O ports enabled) but the card does not
seems
> to hang this time, the leds are still flashing endlessly in a round
> robin fashion. I don't know why this time I don't have the signature
> error... but the module is not loaded anyway. If I launch the command
> again I have the same output except for the last line.
>
> FYI, I have incorporated Michel's changes at the for loop in
> eata2x_detect. I now have :
>
> // for (k = 0; io_port[k]; k++) {
> for (k = 11; k < 27; k++) {
>
> BTW, what is this change supposed to do ?
>
> Something else, what is the 'FORCE_CONFIG' option for ? I've tried
> using it but it doesn't do much. I think it's not used in the code
that
> the driver executes now, only later on.
>
> Thanks for your help and have a nice end of weekend !
>
> Antoine.
------------------------------------------------------------------------
-
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
--
To UNSUBSCRIBE, email to debian-powerpc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: