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. For the other two ranges, it uses two addresses that are intended for use with fixup_bigphys_addr()[1] but seem to target the equivalent physical addresses as in EBOOT. 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 rather random. 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! Uli [1] 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?
