Okay, so 0x43f8 is outside the window.  There are at least two possible
reasons for this:

1) a bug in the code, which "just works" because you don't have
colliding address space use.  (Meaning if pointers are just added, and
there are no bounds checks, it will just work.)

2) pcmcia devices have multiple windows, and the pcmcia framework seems
to enable/disable (alloc..map/unmap..free) these quite a bit.  I think
it is perfectly possible that that you are just seeing multiple accesses
there.  I've not checked the code to see whether this verifies against
your output, but I'd look into it.

    -- Garrett

Sverre Froyen wrote:
> On Saturday 18 February 2006 14:44, Garrett D'Amore wrote:
>   
>> PCMCIA is "funny".
>>
>> There is an attempt to make the bus spaces exposed to code (drivers)
>> either zero based or based off of some small value.  This emulates the
>> IO space addresses of 0xYYY (where YYY is small) that are used in PCs,
>> for which PCMCIA is designed.
>>
>> In real life, the IO spaces could be mapped elsewhere.  It might
>> actually be pretty inconvenient to stick the IO space in low "IO" space,
>> because the space is so crowded on PCs.
>>
>> So it seems to me to be perfectly reasonable that a PCMCIA controller
>> would do this.  I don't think you need to worry about it.
>>     
>
> I understand (I hope) the concept of mapping the pcmcia cards address space 
> into a window in the processors IO space.  What puzzles me is that the window 
> appears to be 0x4000-0x4008 yet the card is being accessed at addresses 
> starting at 0x43f8 (outside of that window).  It seems to me that the window 
> ought to be 0x4000-0x4fff.
>
>   
>> (If you're used to PCs, this might be somewhat surprising, since usually
>> the bus_addr_t is the same as the physical address.  Other platforms,
>> like my Alchemy code for MIPS, don't do this.)
>>
>>     -- Garrett
>>
>> Sverre Froyen wrote:
>>     
>>> Hi,
>>>
>>> With a pcmcia modem card (which does not work with NetBSD) I observe the
>>> following from the dmesg output (attached):
>>>
>>> The function pcmcia_function_configure is called.  It calls the following
>>> functions with the attendant dmesg output in parenthesis:
>>>
>>> pcmcia_config_alloc
>>> 	pccbb_pcmcia_io_alloc
>>> 		rbus_space_alloc
>>> 		(addr 3f8, size 8, mask 3ff, align 400)
>>> 	(alloc port 0x4000+0x8)
>>> pcmcia_config_map
>>> 	pcmcia_io_map
>>> 		pccbb_pcmcia_io_map
>>> 		(window 0 io8 port 4000+8)
>>> 			pccbb_pcmcia_do_io_map
>>> 			(win 0 addr 0x4000 size 0x8 width 8)
>>> 			(start 00 40, stop 07 40, ioctl 00 enable 40)
>>>
>>> When attempting to read or write to the modem, the bus_space read and
>>> write functions are using a bus_space_tag_t value of 0 (IO space) and a
>>> bus_addr_t value of 0x43f8.  This appears to conflict with the dmesg
>>> output from pccbb_pcmcia_io_alloc which says the address space ranges
>>> from 0x4000 to 0x4008 (not including 0x43f8) and also with the output
>>> from
>>> pccbb_pcmcia_do_io_map which maps the same range.
>>>
>>> Comments and help are appreciated!
>>>
>>> Attached is the dmesg output before inserting the modem card (dmesg) and
>>> the additional dmesg output when the card is inserted (dmesg_pcmcia).
>>>
>>> Thanks,
>>>
>>> Sverre
>>>       


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191