On Wed, Apr 16, 2014 at 4:49 PM, Joel Sherrill <joel.sherr...@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.marq...@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.cudm...@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. > > 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 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. > > 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.marq...@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@rtems.org >>>>> http://www.rtems.org/mailman/listinfo/rtems-devel >>>>> >>>>> _______________________________________________ >>>> rtems-devel mailing list >>>> rtems-devel@rtems.org >>>> http://www.rtems.org/mailman/listinfo/rtems-devel >>>> >>> >> > > -- > Joel Sherrill, Ph.D. Director of Research & > developmentjoel.sherr...@oarcorp.com On-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available (256) 722-9985 > >
_______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
