GSOC 2015: Raspberry Pi Low Level Peripherals and SD Card

[Joel Sherrill]

On March 25, 2015 9:17:51 AM CDT, Gedare Bloom <gedare at rtems.org> wrote:
>On Wed, Mar 25, 2015 at 4:49 AM, André Marques
><andre.lousa.marques at gmail.com> wrote:
>> Hello everyone,
>>
>> My GSoC proposal entitled "Raspberry Pi Low Level Peripherals and SD
>Card"
>> can be found for review at:
>>
>>
>https://docs.google.com/document/d/11K0qU3OsbSMhNYkTTWt4kitAbd6uuJBcMfA_07Lg6j8
>>
>> One issue I would like to discuss here is related to the SD card
>support,
>> which as exposed on the proposal the GPIOs to which the SD card is
>connected
>> internally do not have SPI hardware capabilities, meaning that to
>access the
>> card via SPI mode it would have to be bit-banged on those GPIOs (a
>problem
>> on performance). This is more detailed on the proposal, but another
>> alternative would be to use the SD mode instead, with the help of the
>PI's
>> EMMC module, and the SD simplified specifications as documentation
>for the
>> SD protocol. I have already used this setup with success in the past,
>and it
>> should have better performance. In this setup the FreeBSD SD/MMC
>stack may
>> be used (such as the one Sebastian Huber ported last year ->
>>
>https://git.rtems.org/sebh/rtems-libusb.git/tree/rtems/freebsd/dev/mmc?id=3c82a1500da3192de2504a1360e065fd84a1f3a0)
>Is this code in the libbsd.git now?
>
>> which implements the SD protocol also based on the simplified specs.
>This
>> would help avoiding implementing the protocol from scratch (which is
>sort of
>> what I did in my previous effort with the SD card and the PI) and
>would be
>> better for maintenance probably.
>>
>> My issue is then on the feasibily (licence wise) of having the
>FreeBSD SD
>> stack or having code based on the SD Simplified Specs on the RTEMS
>tree.
>>
>FreeBSD code should be fine. The complexity of getting libbsd working
>could be the real stumbling block. But I think others will be working
>on the same problem too, so there may be some ability to share
>knowledge.

The USB stack works at least for removable media and the TCP/IP stack has been reported to do GigE wirespeed on a couple of platforms. It just doesn't have all the target support the old stack already does. And it is larger than the old stack.

There may be room for two implementations if the license and portability are ok.

>> In SPI mode an implementation of the protocol can be found in
>> libchip/i2c/spi-sd-card.*, which could in that case be used/improved
>further
>> during the project, if it is decided it is best to use SPI mode. This
>uses
>> the libi2c API, which is deprecated for I2C but, as I understand,
>still
>> stands as the API for SPI (information about that would also be
>> appreciated).
>>
>It's just the no one has replaced it yet! There seem to be multiple
>efforts going on now to get more driver-like frameworks into RTEMS.
>
>> Thanks,
>> André Marques.
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>_______________________________________________
>devel mailing list
>devel at rtems.org
>http://lists.rtems.org/mailman/listinfo/devel

--joel