Ulrich Eckhardt wrote:
Pete Popov wrote:
Looking at EBOOT (a bootloader for win CE that boots off the
compactflash), it tries to access the IDE interface at address 0x1a00000
for io_addr and 0x1a00000e for control, let's see if I can find any IDE
hardware at that address...
Uhm, I don't think you'll resolve this that easily. There is some code that
needs to go in the au1x00 socket driver which means you would have to
understand pretty well how this thing works. Ultimately the addresses
you'll probe are very high ioremapped addresses, since the pcmcia
attribute, common mem, and i/o are 36 bit physical addresses.
Looking at EBOOT, it creates these mappings here in the TLB:
0xf 0000 0000 -> 0x1a00 0000 (IO)
0xf 4000 0000 -> 0x1c00 0000 (attrib)
0xf 8000 0000 -> 0x1e00 0000 (mem)
each time mapping 32MiB.
In the Linux PCMCIA code, I see that only the IO range above gets ioremap()ed,
and only 4KiB thereof.
That's all that's really needed.
For the other two ranges, it uses two addresses that
are intended for use with fixup_bigphys_addr() but seem to target the
equivalent physical addresses as in EBOOT.
Correct. The pcmcia stack will call ioremap on those phys addresses when
I tried simply ioremap()ing the IO region and looked for an ATA interface at
the beginning of that range, but the contents of that memory seem to be
Well, that's the I/O registers. If you remapped them correctly and you are
actually talking to the device, then the data should not be so random. But the
attribute memory is a better first test. Hack up the driver to ioremap the attr
space after a card is inserted, dump some of that data, and then free the region
-- just a simple test to make sure the device is powered and you're actually
talking to it.
I'll next try to remove both PCMCIA and IDE drivers, just to
make sure they don't interact in any unforseeable way with my ad-hoc code,
but that's scheduled for tuesday.
I also found www.ata-atapi.com/atadrvr.zip, which contains low-level driver
sourcecode and examples, so I have something to read over the weekend. ;)
Thank you all for your help!
 Why the difference in the handling of the three ranges? Also, what
additional effect does ioremap() have when compared to using the TLB? Is it
that ioremap() is the Right Way(tm) on any architecture
while TLB is the way that works only on MIPS?
No, other processors have TLBs too. I assume you're refering to the yamon vs
Linux kernel. Yamon just uses statically setup TLBs to access those addresses.
When you call ioremap in the kernel, the kernel will setup the necessary tables
to be able to map and handle those phys addresses only when needed. Those TLBs
are flushed randomly, and then reentered by the kernel dynamically when needed
because of a page fault.