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-0001.html>
More information about the devel
mailing list