Point to sample SPI for MMC card driver?

Gene Smith gds at chartertn.net
Wed Oct 15 22:40:44 UTC 2008


Robert S. Grimes wrote:
> Gene Smith wrote:
>>> Sorry, can't help you here, but you do want to be fairly current.
>>> The libi2c SPI support has matured somewhat since I started (around
>>> 4.8), and if you want to use the spi-sd-card driver, you'll need to
>>> make sure you're based on at least 4.9 libi2c.  In particular, you'll
>>> want to support the idle_char field of the transfer parameters
>>> structure rtems_libi2c_tfr_mode_t.  See my latest posts regarding
>>> "Card Specific Data".

Yes, I am using 4.9.0 now so no problem. I remember you said something 
about adding a new field to a struct for some reason. Is this what you 
are referring to?

I need to go back and re-read your threads, print them out, tape them to 
the wall, whatever it takes. :)

>>>
>>> FWIW - I started with the powerpc/mpc5566evb SPI driver, as Sebastian
>>>  suggested - I think you know the thread...
>>>     
>> Bob,
>> Yes sd-card-init.c (in libbsp) and dspi.c (in libcpu) go together, right?
>>   
> Well, the former is the BSP code that sets up the spi-sd-card driver - I 
> wrote a similar function for my BSP/application.  The latter is, I 
> believe, the low-level SPI driver for the mpc55xxevb BSP.
> 
> Hmm... Looking back, I believe I've confused myself a bit.  My "SPI 
> driver" is actually based on the one in powerpc/gen83xx/spi and 
> libcpu/mpc83xx/spi.  Note that the former is the "low-level" code that 
> is BSP-specific, while the latter is chip-specific - hence, the split 
> you've noticed before.  Here is some explanation that Thomas had 
> provided to me:
> 
>     Actually the mpc83xx driver is split into two parts (or three):
>     - One is formed by the extended libi2c, it now supports also SPI devies.
>     - Then we have the "real" driver in libcpu/mpc83xx/spi, which does
>     the actual data transfers and has most of the interfaces needed.
>     - And finally, since most SPI implementations need dedicated
>     GPIO-lines to select the addressed hardware device, we need a small
>     board specific layer. This (and the encapsulated initialization) is
>     in libbsp/powerpc/gen83xx.
> 
>     I gues the last two pieces could be integrated into one for the
>     virtex. If somebody wants to use the SPI with different GPIO lines
>     to select the devies, the BSP should get some conditional
>     compilation stuff.
> 
> As for my code to use the SD card driver, _that_ was based on the
> mpc55xx_sd_card_init() code. Sorry if I've confused you on this - I'm
> still getting it straight myself!

I thought in your first post on this a while back you said you based 
your SPI driver on "vertex". But when I look under vertex in libbsp I 
see nothing about SPI. Just curious about that.

OK, so I will just use these two as my examples and stop looking at 
others.  They seem like a good starting point.

> 
> 
>> However, I don't see where mpc55xx_sd_card_init() is called. Would this 
>> be called from the "predriver_hook" referred to in the readme?
>>   
> You know, to be honest, I don't really know where the best place is.  
> For me, my BSP really supports several different variants, based on 
> different FPGA configurations; only one will use the SD cards.  Factor 
> in that I haven't yet mastered (or even passed the "rank novice" phase)  
> autoconf/automake, I don't intend to call my equivalent in the BSP 
> itself.  Instead, I'll do it in my application startup.  Not necessarily 
> the "right" place to put it, but it saves me a lot of effort that I just 
> cannot afford right now - the client isn't that interested...

The function I referred to above, mpc55xx_sd_card_init() in a bsp file 
just seems to be an isolated function that is not called. Maybe it is 
just an example of the code to go through to mount the SD card fs and 
use the API? (There is a debug message in it that  prints  "Task 
Started" so it sort of implies it is user level code.)

So if I understand correctly, you have taken the above file from libcpu 
(the main driver) and libbsp (board specific stuff + plus sd card 
specific stuff), modified them for your special h/w and made them part 
of your application and start everything there. They are not currently 
in your libcpu or libbsp.




More information about the users mailing list