On 2005-01-09 matt@bodgit-n-scarper.com wrote:

> Just idly browsing the linux source tree for some clues if there's
> something unusual in the pcic probe, I saw that the ISA port window is
> defined to be 0x15000000-0x18000000 instead of 0x14000000-0x18000000 for
> the Workpad, although I haven't built and booted a Linux kernel yet to
> see what it does on the Workpad hardware. Would that ISA range make any
> difference? I don't understand why the pcic hardware is appearing at
> multiple memory locations although I understand in a basic fashion why
> the I/O ports are memory-mapped on MIPS hardware.

  My clio does the same thing.  I suspect that the pcmcia chip is the only
thing on the bus and they only connect the minimum number of address
lines.  I tried with isaportoffset 0 on my clio 1000 and it seems to work
exactly the same.

> I've trimmed the kernel config down so it should only contain config for
> the Workpad hardware, this doesn't seem to make any difference. Enabling
> arbitrary options seem to change when it works, maybe it's a subtle
> timing issue between jumping from WinCE and probing the hardware?

  I have never seen a socket not detected, so your problems may be
unrelated to mine, although it seems reasonable to me that they might be
related.  I did some more experiments, but I still have no idea what the
problem could be.  My usb card works perfectly on the clio 1000 if I use
io offset 2 for data access (the card has a 4 byte io window and repeats
data access on the last three; offset 3 is the same as or worse than 1).
pcic uses address/data access bytes also.  The particular kernel,
particular boot, bus_space implementation, and pre-writing the target
buffer all seem to have separate noticeable effects.  Clearing the buffer
first causes the data transfered from USB CD to be mostly ok, but I still
see a few bad bytes (in some 40k transfers) in some kernels and it still
gets some bad reads at times in other places where I didn't write the
target memory first.  Disabling cache does not seem to have much, if any,
effect (this time I saw the K0 bits in the Config cp0 register and
disabled it that way).  The uncached kernel without buffer write had the
same effect as with cache, and the one uncached with buffer write kernel
that I tested seemed to work perfectly.  Some of the kernels I tried are
from the release branch and some are -current.  The first two kernels I
tried with buffer write from the release branch hung solid when accessing
the cd, but when I tried to add an led blink in vr_intr (I didn't remember
to try vrgiu_intr_led first) it didn't hang and I have not seen any other
kernels I have tested hang.

Matthew Orgass
darkstar@city-net.com