Raspberry Pi SD card support

Alan Cudmore alan.cudmore at gmail.com
Thu Apr 17 18:21:41 UTC 2014

On 4/17/2014 5:42 AM, Andre Marques wrote:
> On 04/17/14 03:22, Alan Cudmore wrote:
>> On Wed, Apr 16, 2014 at 4:49 PM, Joel Sherrill 
>> <joel.sherrill at oarcorp.com <mailto:joel.sherrill at oarcorp.com>> wrote:
>>     On 4/16/2014 2:06 PM, Alan Cudmore wrote:
>>>     On Thu, Apr 10, 2014 at 7:11 PM, Andre Marques
>>>     <andre.lousa.marques at gmail.com
>>>     <mailto:andre.lousa.marques at gmail.com>> wrote:
>>>         On 04/04/14 20:19, Joel Sherrill wrote:
>>>             On 4/4/2014 1:15 PM, Gedare Bloom wrote:
>>>                 The license looked fine to me.
>>>             +1
>>>             As always, we just need to be careful on a file per file
>>>             basis just in case
>>>             something else in rpi-boot has a different license.
>>>         All files in rpi-boot use a similar licence, so I will be
>>>         using some code from rpi-boot as a base for this.
>>>     Great.
>>>                 On Thu, Apr 3, 2014 at 10:06 PM, Alan Cudmore
>>>                 <alan.cudmore at gmail.com
>>>                 <mailto:alan.cudmore at gmail.com>> wrote:
>>>                      From my limited research, it looks like the
>>>                     emmc controller in the Raspberry
>>>                     Pi BCM2835 may be the way to go.
>>>                     It looks like it is a high level controller for
>>>                     the SD/MMC card slot on the
>>>                     Pi.
>>>                     Since this is a custom controller, I don't think
>>>                     there would be an existing
>>>                     driver in RTEMS.
>>>                     It seems that this emmc controller in the Pi may
>>>                     handle different types of
>>>                     cards, and at a higher level than just using the
>>>                     SPI bus to access the card.
>>>                     ( This is based on some searches of
>>>                     conversations on the raspberry pi forums
>>>                     , not my experience )
>>>                     You would have to write a driver for this emmc
>>>                     controller and provide the
>>>                     interface to libblock for the file system
>>>                     interface on RTEMS. The code you
>>>                     have linked above for rpi-boot looks like it has
>>>                     a permissive license, so it
>>>                     *may* be possible to use this code in the RTEMS
>>>                     driver. There is some other
>>>                     potentially useful code in there too.
>>>         The mailbox access, mmio read and write and the timer code
>>>         will also be usefull, and not only for emmc. This timer code
>>>         differs from the misc/timer.h currently in the raspberrypi
>>>         BSP, as it waits a certain amount of time (until some
>>>         register gets updated). The misc/timer.h is a benchmark
>>>         timer, so one of them would have to be renamed or reorganized.
>>>     Can an RTEMS timer be used for the mailbox communication?
>>>     Also, I don't think the benchmark timer code in the RTEMS
>>>     Raspberry Pi BSP is functional.
>>     Do you mean rtems_timer_XXX or the timer in the BSP?
>> I mean the rtems_timer_ api. Maybe we can use this, or other RTEMS 
>> features to implement the mailbox interface rather than just going 
>> directly to the timer hardware like we see in the "bare metal" examples.
> Maybe the "timer" concept here is a little misleading. I was talking 
> about a wait with timeout, until some register gets updated. The 
> rtems_timer api schedules a routine to be executed after some period 
> of time, but the register may (and should) be updated before the timeout.
> I am not sure if this would be recommended, but using the rtems_timer 
> api a timer could be set for a period of time (the timeout), and while 
> the timer is going the driver would check if the register has been 
> updated. If so the timer would be cancelled. Is this good practice 
> with the rtems_timer api?

I agree that the rtems_timer might not be the best mechanism for the 
waiting on the mailbox.
If the CPU<->GPU interface supports interrupts, then a non-blocking 
driver could be written.
Otherwise, what is the best approach?
  - a sleep call
  - polling a status register

While I am on the subject of polling, I just remembered that the UART 
driver in the BSP does not support interrupts. We should look at this 
sometime too.

>>     The timer driver in the BSP is strictly for benchmarking --
>>     nothing else. It is used
>>     by the tmtests and psxtmtests. It should not be used for any
>>     other purpose.
>>     How does the mailbox work? Describe it and we can figure out how
>>     to best address
>>     it.
>> The mailbox is the interface between the Video Core GPU and the ARM 
>> processor on the Pi. Here are some docs:
>> https://github.com/raspberrypi/firmware/wiki/Mailboxes
>> https://github.com/raspberrypi/firmware/wiki/Accessing-mailboxes
>> https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface
> The mailbox interface is a register that has several channels ("mail 
> accounts") for different resources on the board, so a driver sends a 
> buffer with a request (an "email") to one of them and gets answers. 
> This is an abstraction layer mainly usefull to communicate with the 
> GPU since its documentation isn't available (that is how I see it), 
> but can be used to get other types of information, not related with 
> the GPU.
> Any work with the GPU, however, will probably need to use this interface.
> In practice it is just a matter of dealing with reading and writting 
> to the mailbox registers, following a small protocol. This could be 
> put into the misc directory in the Raspberry Pi BSP.
> One thing I haven't found on the Raspberry Pi BSP is a memory barrier. 
> The memory mapped i/o to the registers shoud have a memory barrier 
> around the read and writes to a peripheral when more than one 
> peripheral is being used, according to the bcm2835 datasheet (page 7).
> http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
Good point. Is this memory barrier an assembly instruction? Should we 
create a couple of macros that generate the inline assembly?

>> The details of the GPU have been closed, and the linux port has 
>> relied on a binary blob for the GPU firmware, but Broadcom recently 
>> took a huge step in opening it up:
>> http://www.raspberrypi.org/a-birthday-present-from-broadcom/
>> Hopefully this will help improve the understanding of this interface.
>>>     I have been contacted by someone who is currently working on a
>>>     console driver for the BSP, and has been able to display fonts.
>>>     We may want to include him, because I think the graphics code
>>>     uses mailbox communication to the GPU.
>>>     It is very interesting that the GPU is running a commercial
>>>     RTOS, and we will be communicating to it with RTEMS.
>>     :)
>>>         My plan was to have at the root of the raspberrypi BSP a
>>>         folder "emmc" for the emmc driver code, and the mailbox,
>>>         mmio and timer on the misc folder, with the headers on the
>>>         include folder. What do you think?
>>>         I have been trying the rpi-boot emmc code for the past week,
>>>         and I modified the hello test to use the emmc driver (an
>>>         overly simplified version of the rpi-boot, just to read the
>>>         slot info register for now), and my compilation process has
>>>         been:
>>>         1. Add/change files in Raspberrypi BSP
>>>         2. Update Makefile.am
>>>         3. Run bootstrap -p and bootstrap from the RaspberryPi BSP
>>>         folder
>>>         4. (Re)configure RTEMS
>>>         5. make and make install RTEMS from the root folder
>>>     That is pretty much what I do. Although it might be possible to
>>>     test drivers and code in the RKI image, then integrate it into
>>>     the RTEMS tree when it is ready.
>>     --enable-maintainer-mode is supposed to track regenerating the
>>     Makefile.in
>>     and configure files when you modify Makefile.am or configure.ac
>>     <http://configure.ac>.
>>     The current build system has a serious deficiency in that it does
>>     **not**
>>     track the dependency of the test executables on any .a or .h file
>>     from RTEMS.
>>     So the best solution for quick builds is usually to remove the
>>     executable you
>>     are testing and then run make.
>>     Step 3 above is the minimum for a bootstrap. bootstrap -p is only
>>     needed
>>     when you add/delete/move .h files.
>>>         I have been using the --enable-maintainer-mode, but I am not
>>>         sure about exacly what it simplifies, because I always
>>>         needed to do those steps for it to compile and link correctly.
>>>     I don't know what this does either..
>>     Just tracks dependencies on generated Makefile/configure related
>>     files back
>>     to their source.
>>>     Alan
>>>         --André Marques
>>>                     I'll have to try the serial bootloader, I am
>>>                     also close to ordering an
>>>                     inexpensive JTAG adapter to try loading and
>>>                     debugging through JTAG. uboot is
>>>                     another possibility, using a TFTP server.
>>>                     Alan
>>>                     On Wed, Apr 2, 2014 at 12:02 PM, Andre Marques
>>>                     <andre.lousa.marques at gmail.com
>>>                     <mailto:andre.lousa.marques at gmail.com>> wrote:
>>>                         Hello,
>>>                         I'm intending to work in the SD card support
>>>                         for the Raspberry Pi BSP,
>>>                         using the SD mode instead of the SPI mode.
>>>                         The references I have gathered so far for
>>>                         this are as follows:
>>>                         The Raspberry Pi SOC guide: Broadcom BCM2835
>>>                         Peripherals Guide (Chapter 5
>>>                         - EMMC)
>>>                         The simplified SD standard -
>>>                         https://www.sdcard.org/downloads/pls/simplified_specs/
>>>                         And the following github code -
>>>                         https://github.com/jncronin/rpi-boot/blob/master/emmc.c
>>>                         There is also the libchip/i2c/spi-sd-card
>>>                         libi2c driver, which can also be
>>>                         a reference (even though it uses SPI).
>>>                         Now, the questions:
>>>                         Should I use the Generic Disk Device driver,
>>>                         as the
>>>                         libchip/i2c/spi-sd-card ?
>>>                         Is there any driver using the SD mode for sd
>>>                         card access, or using an emmc
>>>                         interface currently in the RTEMS code base?
>>>                         I haven't found any.
>>>                         On a side note, I managed to send RTEMS
>>>                         applications to the RPi though the
>>>                         UART interface using the xmodem protocol.
>>>                         For that I used the following bootloader
>>>                         https://github.com/dwelch67/raspberrypi/tree/master/bootloader05
>>>                         It takes me 2 minutes to send 1 MB of data
>>>                         to the RPi, but this could be
>>>                         improved if it used 1024 byte block transfer
>>>                         instead of the default of 128.
>>>                         The bootloader loads the transfered program
>>>                         to memory and runs it. Then the
>>>                         RPi must be rebooted so a new program can be
>>>                         sent.
>>>                         It may not be the best way, but only
>>>                         requires an usb-to-uart cable, and
>>>                         avoids the current SD card "dance" to run
>>>                         programs on the Pi.
>>>                         Thank you for your time.
>>>                         --André Marques
>>>                     _______________________________________________
>>>                     rtems-devel mailing list
>>>                     rtems-devel at rtems.org <mailto:rtems-devel at rtems.org>
>>>                     http://www.rtems.org/mailman/listinfo/rtems-devel
>>>                 _______________________________________________
>>>                 rtems-devel mailing list
>>>                 rtems-devel at rtems.org <mailto:rtems-devel at rtems.org>
>>>                 http://www.rtems.org/mailman/listinfo/rtems-devel
>>     -- 
>>     Joel Sherrill, Ph.D.             Director of Research & Development
>>     joel.sherrill at OARcorp.com  <mailto:joel.sherrill at OARcorp.com>         On-Line Applications Research
>>     Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>     Support Available(256) 722-9985  <tel:%28256%29%20722-9985>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140417/c72690bd/attachment.html>

More information about the devel mailing list