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.sherr...@oarcorp.com <mailto: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
<mailto: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
<mailto: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.
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.marq...@gmail.com
<mailto: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 <mailto:rtems-devel@rtems.org>
http://www.rtems.org/mailman/listinfo/rtems-devel
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org <mailto:rtems-devel@rtems.org>
http://www.rtems.org/mailman/listinfo/rtems-devel
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.com <mailto:joel.sherr...@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>
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
