AT91RM9200 CF problem

[Mathieu Deschamps]

Hello Pavel,

I've permitted myself to cc linux-arm list on Steven Scholz advice 
since there are people using pcmcia on AT91RM9200 successfully there.

On Tuesday 27 June 2006 21:45, Pavel Roskin wrote:
> Hello, Mathieu!
>
> On Tue, 2006-06-27 at 19:27 +0200, Mathieu Deschamps wrote:
> > Hello,
> >
> > I have a problem compiling 3.2.8 against 2.6.14. Priorily, coming from
> > 3.2.7 and 3.2.4 unsuccessful builds :  I guess that's a bad config.
>
> Why would you want to use pcmcia-cs with kernels that support
> pcmcia-utils?  pcmcia-cs support remains in Linux 2.6.13 and newer only
> for backward compatibility.
>

ack.

> > I have a custom AT91RM9200 based board which integrates a PCMCIA CF
> > circuitry and intent to plug flash pcmcia device (ide_cs module) and
> > wireless device (orinoco_cs modules).
>
> ... even more so on embedded systems, where you recompile userspace
> anyway.  Why would you want extra backward compatibility code in the
> kernel and the cardmgr process running all the time?

I have no specific desire... I'll try both and keep up the one that can be 
carried out quick and pointfully. 

Will diethotplug work well with pcmciautils ? 
http://kernel.org/pub/linux/utils/kernel/pcmcia/cardmgr-to-pcmciautils.html
is silent on what type/version of hotplug is supported.

[...]

>
> It would be better if you used POSIX locale when you are going to report
> the messages.  

Using POSIX locale when reporting ? What do you mean, is
my actual (LANG=) en_US.UTF-8 not one  ?

>Not that I cannot understand "Interruption" at all, but I
> may be missing some nuances.  Can it be that the build was interrupted,
> e.g. by Ctrl-C?
>

Yes stopped by me. I believed such a none fatal warning ( 'struct 
pcmcia_socket' declared inside parameter list) to become soon
or later a fatal one. Plus : 
'warning: its scope is only this definition or declaration, which is probably 
not what you want'. You have to admit this can't make you feel confident 
about it. But if you say that is ok, well... I tell compiler this is what I 
want :)

> > #cardmgr
> > cardmgr[1436]: no pcmcia driver in /proc/devices
>
> Can it be that you didn't enable PCMCIA backward compatibility in the
> kernel (CONFIG_PCMCIA_IOCTL)?

Exact ! I didn't. I mean I did but recently 
reconfig/rebuilding  after coming all over it again and then I didn't. Thanks 
for the catch, it works. You know while testing different pcmcia 
package...BTW I can safely disable that backward compat. option if I intent 
to use only pcmcia-utils, right ? Else will it hurts if I leave it enabled 
while using pccardctl ?

-*-
Ok, now using pcmciautils-0.14 pccardct, I (still) can't read a Flash memory 
card (on both pcmcia design however) on card insertion my log reports:

Jun 27 19:02:52 zephyr-B kern.debug kernel: cs: pcmcia_socket0: 
pcmcia_read_cis_mem attrib mem
Jun 27 19:02:52 zephyr-B kern.debug kernel: at91_cf: At91_cf set_mem_map<7>
Jun 27 19:02:52 zephyr-B kern.debug kernel: cs: pcmcia_socket0:   0x52 0x00 
0x00 0x00 ...
Jun 27 19:02:52 zephyr-B kern.debug kernel: cs: pcmcia_socket0: 
pcmcia_read_cis_mem(1, 0x402, 2)
Jun 27 19:02:52 zephyr-B kern.debug kernel: cs: pcmcia_socket0: 
pcmcia_read_cis_mem attrib mem
[...] Repeated several times.
Jun 27 19:02:52 zephyr-B kern.debug kernel: at91_cf: At91_cf set_mem_map<7> 
EINVAL!<7>cs: pcmcia_socket0: pcmcia_read_cis_mem(0, 0x0, 5)
Jun 27 19:02:52 zephyr-B kern.debug kernel: cs: pcmcia_socket0: 
pcmcia_read_cis_mem attrib mem
Jun 27 19:02:52 zephyr-B kern.debug kernel: at91_cf: At91_cf set_mem_map<7>
Jun 27 19:02:52 zephyr-B kern.debug kernel: cs: pcmcia_socket0:   0x52 0x00 
0x00 0x00 ...
Jun 27 19:02:52 zephyr-B kern.debug kernel: ds: invalid CIS or invalid 
resources (#tuples=0,chains?=0)


There is no device in /sys/bus/pcmcia/devices/ also :

# pccardctl ident
Socket 0:
  no product info available
# pccardctl status
Socket 0:
  3.3V 16-bit PC Card

Back in time, I've already exposed this situation to Steven Scholz in a thread 
intitled 'AT91RM9200 CF Ambicom WL1100C issue...'  on linux-pcmcia in Feb 
2006 as I intent primarily to carried out a wifi card support. In brief, as 
both flash card and wifi card didn't (and still don't) work, we have conclude 
to a more hardware related issue:

But board setup and pin definition have been double even triple checked.
Neither data or address buffers are closed, but I worry about not finding 
anywhere EBI_CFGR's DBPUC (data bus pull-up configuration) register 
set to 1. Should it been un-pulled up so data lines are free ? Is it done 
somewhere and miss me ?




Regards,
Mathieu Deschamps