On Wed, Feb 27, 2002 at 12:26:44PM +0100, Agecodagis F. Moreau wrote:
> hi every/arm/body!
> I'm busy with a, i think, ground zero hardware problem.
> Trying to modify i82365.c source to get positive probe result from my so
> marvelous new self designed Pcmcia card :=) plugged on a CDB89712 board,
> kernel 2.4.6
> My card is responding a 0x200003E0. I performed an ioremap(...) in
> initialisation routines. It works fine.
> BUT......
> Trying to read and write the PCMCIA chip using the ioremaped address gives
> the following result:
> The hardware CS2 and on my board generated /IOR and /IOW move correctly. So
> ioremap works fine.
> Writing 0x3A at physical adress 0x200003e0 is ok.
> Reading 0x32 at physical adress 0x200003e1 is ok. (I cleaned my old
> oscilloscope to check each bit one by one....)
> All timings seems also ok.
>
> So, on the hardware side, all is ok!
>
> But the inb(port+1); doesn't return me the correct value (0x32).
>
> More: I tried a mad loop only making reads on bus after having removed le
> plugged card and changed by hand some bits on the data bus cause no other
> access on the data bus was taking place. Never any change has been seen in
> returned result! Hardware signals are one more time ok but......
>
> Somebody has any idea? Why outb works and inb doesn't?
You're running into the good old evil ISA bus problem. Its called IOCS16.
Ignore this signal at your peril.
Basically, ISA can transfer odd addressed bytes on either the low or the
high byte lane. The ISA standard defines the following signals and states
from the CPU to the peripheral:
A0 /BHE
0 0 Whole 16-bit word read/write
1 0 Odd address read/write on *either* byte lane 0 *or* byte lane 1
defined by the IOCS16 signal from the peripheral being addressed.
0 1 Even address read/write on byte lane 0.
The reason we have IOCS16 is to allow ISA based systems to address either
8-bit peripherals or 16-bit peripherals.
IIRC, the 82365 is internally an 8-bit device, which means that it will
always expect data to be transferred on byte lane 0 no matter whether the
address is 0 or 1. However, the ARM CPUs expect bytes to be transferred
on byte lane (address & 3). However, this is not the full solution.
PCMCIA cards plugged in also have an IOCS16 signal, and can be either
8-bit or 16-bit cards.
To get this to work, you need to add some byte lane stearing logic to
move data between the byte lanes to match what the peripheral expects
using the StrongARM bytelane enable signals and IOCS16. Luckily, there
aren't that many combinations...
D31-D24 --- B4 -------+
|
D23-D16 --- B3 ---+ |
| |
D15-D8 --------------+---+----- B2 ----- SD15-SD8
| `-- B1 --.
D7-D0 ----------+------- B0 -----+----- SD7-SD0
Obviously, B0, B1, B2, B3 and B4 need to have a direction control - the
read/write line is probably sufficient (check though).
The rules should be (although they need checking):
B3 and B4 needs to be enabled whenever you access your "ISA bus" IO and
memory space.
B0 needs to be enabled when performing an even address access or 16-bit
access.
B1 needs to be enabled if you're performing an odd 8-bit access and the
peripheral indicates that it is an 8-bit device on an odd access.
B2 needs to be enabled if you're performing a 16-bit access or the
peripheral indicates that it is a 16-bit device on an odd access.
Note that if you're not going to use ((addr & 2) == 2) then you can
forget about B3 and B4.
_______________________________________________
http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
http://www.arm.linux.org.uk/armlinux/mailinglists.php
Please visit the above addresses for information on this list.
