<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 04/17/14 03:22, Alan Cudmore wrote:<br>
</div>
<blockquote
cite="mid:CAJrjN72cofLqdbUeXAdzNCgiNy=QT1HAVDiihLi7tODF1-DCAg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Apr 16, 2014 at 4:49 PM, Joel
Sherrill <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<div class="h5"> <br>
<div>On 4/16/2014 2:06 PM, Alan Cudmore wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Apr 10, 2014
at 7:11 PM, Andre Marques <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:andre.lousa.marques@gmail.com"
target="_blank">andre.lousa.marques@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>On 04/04/14 20:19, Joel Sherrill
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 4/4/2014 1:15 PM, Gedare Bloom
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The license looked fine to me.<br>
</blockquote>
+1<br>
<br>
As always, we just need to be careful
on a file per file basis just in case<br>
something else in rpi-boot has a
different license.<br>
</blockquote>
<br>
</div>
All files in rpi-boot use a similar
licence, so I will be using some code from
rpi-boot as a base for this.</blockquote>
<div><br>
</div>
<div>Great.</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br>
<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Thu, Apr 3, 2014 at 10:06 PM,
Alan Cudmore <<a
moz-do-not-send="true"
href="mailto:alan.cudmore@gmail.com"
target="_blank">alan.cudmore@gmail.com</a>>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
From my limited research, it
looks like the emmc controller in
the Raspberry<br>
Pi BCM2835 may be the way to go.<br>
It looks like it is a high level
controller for the SD/MMC card
slot on the<br>
Pi.<br>
<br>
Since this is a custom controller,
I don't think there would be an
existing<br>
driver in RTEMS.<br>
<br>
It seems that this emmc controller
in the Pi may handle different
types of<br>
cards, and at a higher level than
just using the SPI bus to access
the card.<br>
( This is based on some searches
of conversations on the raspberry
pi forums<br>
, not my experience )<br>
<br>
You would have to write a driver
for this emmc controller and
provide the<br>
interface to libblock for the file
system interface on RTEMS. The
code you<br>
have linked above for rpi-boot
looks like it has a permissive
license, so it<br>
*may* be possible to use this code
in the RTEMS driver. There is some
other<br>
potentially useful code in there
too.<br>
</blockquote>
</blockquote>
</blockquote>
<br>
</div>
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.<br>
<br>
</blockquote>
<div><br>
</div>
<div>Can an RTEMS timer be used for the
mailbox communication? </div>
<div>Also, I don't think the benchmark timer
code in the RTEMS Raspberry Pi BSP is
functional.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
Do you mean rtems_timer_XXX or the timer in the BSP?<br>
</div>
</blockquote>
<div><br>
</div>
<div>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. </div>
<div> </div>
</div>
</div>
</div>
</blockquote>
<br>
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. <br>
<br>
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?<br>
<br>
<blockquote
cite="mid:CAJrjN72cofLqdbUeXAdzNCgiNy=QT1HAVDiihLi7tODF1-DCAg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
The timer driver in the BSP is strictly for benchmarking
-- nothing else. It is used<br>
by the tmtests and psxtmtests. It should not be used for
any other purpose.<br>
<br>
How does the mailbox work? Describe it and we can figure
out how to best address<br>
it. <br>
</div>
</blockquote>
<div><br>
</div>
<div>The mailbox is the interface between the Video Core GPU
and the ARM processor on the Pi. Here are some docs:</div>
<div><a moz-do-not-send="true"
href="https://github.com/raspberrypi/firmware/wiki/Mailboxes">https://github.com/raspberrypi/firmware/wiki/Mailboxes</a><br>
</div>
<div><a moz-do-not-send="true"
href="https://github.com/raspberrypi/firmware/wiki/Accessing-mailboxes">https://github.com/raspberrypi/firmware/wiki/Accessing-mailboxes</a><br>
</div>
<div><a moz-do-not-send="true"
href="https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface">https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface</a><br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
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. <br>
<br>
Any work with the GPU, however, will probably need to use this
interface.<br>
<br>
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.<br>
<br>
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).<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf">http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf</a><br>
<br>
<blockquote
cite="mid:CAJrjN72cofLqdbUeXAdzNCgiNy=QT1HAVDiihLi7tODF1-DCAg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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:</div>
<div><a moz-do-not-send="true"
href="http://www.raspberrypi.org/a-birthday-present-from-broadcom/">http://www.raspberrypi.org/a-birthday-present-from-broadcom/</a><br>
</div>
<div><br>
</div>
<div>Hopefully this will help improve the understanding of
this interface.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div class="">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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. </div>
<div><br>
</div>
<div>It is very interesting that the GPU is
running a commercial RTOS, and we will be
communicating to it with RTEMS.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
:)
<div class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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?<br>
<br>
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:<br>
<br>
1. Add/change files in Raspberrypi BSP<br>
2. Update Makefile.am<br>
3. Run bootstrap -p and bootstrap from the
RaspberryPi BSP folder<br>
4. (Re)configure RTEMS<br>
5. make and make install RTEMS from the root
folder<br>
<br>
</blockquote>
<div>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.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
--enable-maintainer-mode is supposed to track
regenerating the Makefile.in<br>
and configure files when you modify Makefile.am or <a
moz-do-not-send="true" href="http://configure.ac"
target="_blank">configure.ac</a>.<br>
<br>
The current build system has a serious deficiency in
that it does **not** <br>
track the dependency of the test executables on any .a
or .h file from RTEMS.<br>
So the best solution for quick builds is usually to
remove the executable you<br>
are testing and then run make.<br>
<br>
Step 3 above is the minimum for a bootstrap. bootstrap
-p is only needed<br>
when you add/delete/move .h files.
<div class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br>
</blockquote>
<div><br>
</div>
<div>I don't know what this does either..</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
Just tracks dependencies on generated Makefile/configure
related files back<br>
to their source.
<div>
<div class="h5"><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Alan</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
--André Marques
<div>
<div><br>
<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I'll have to try the serial
bootloader, I am also close to
ordering an<br>
inexpensive JTAG adapter to try
loading and debugging through
JTAG. uboot is<br>
another possibility, using a
TFTP server.<br>
<br>
Alan<br>
<br>
<br>
<br>
<br>
On Wed, Apr 2, 2014 at 12:02 PM,
Andre Marques<br>
<<a moz-do-not-send="true"
href="mailto:andre.lousa.marques@gmail.com"
target="_blank">andre.lousa.marques@gmail.com</a>>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hello,<br>
<br>
I'm intending to work in the
SD card support for the
Raspberry Pi BSP,<br>
using the SD mode instead of
the SPI mode.<br>
<br>
The references I have gathered
so far for this are as
follows:<br>
<br>
The Raspberry Pi SOC guide:
Broadcom BCM2835 Peripherals
Guide (Chapter 5<br>
- EMMC)<br>
<br>
The simplified SD standard -<br>
<a moz-do-not-send="true"
href="https://www.sdcard.org/downloads/pls/simplified_specs/"
target="_blank">https://www.sdcard.org/downloads/pls/simplified_specs/</a><br>
<br>
And the following github code
-<br>
<a moz-do-not-send="true"
href="https://github.com/jncronin/rpi-boot/blob/master/emmc.c"
target="_blank">https://github.com/jncronin/rpi-boot/blob/master/emmc.c</a><br>
<br>
There is also the
libchip/i2c/spi-sd-card libi2c
driver, which can also be<br>
a reference (even though it
uses SPI).<br>
<br>
Now, the questions:<br>
<br>
Should I use the Generic Disk
Device driver, as the<br>
libchip/i2c/spi-sd-card ?<br>
<br>
Is there any driver using the
SD mode for sd card access, or
using an emmc<br>
interface currently in the
RTEMS code base? I haven't
found any.<br>
<br>
On a side note, I managed to
send RTEMS applications to the
RPi though the<br>
UART interface using the
xmodem protocol.<br>
<br>
For that I used the following
bootloader<br>
<br>
<a moz-do-not-send="true"
href="https://github.com/dwelch67/raspberrypi/tree/master/bootloader05"
target="_blank">https://github.com/dwelch67/raspberrypi/tree/master/bootloader05</a><br>
<br>
It takes me 2 minutes to send
1 MB of data to the RPi, but
this could be<br>
improved if it used 1024 byte
block transfer instead of the
default of 128.<br>
The bootloader loads the
transfered program to memory
and runs it. Then the<br>
RPi must be rebooted so a new
program can be sent.<br>
<br>
It may not be the best way,
but only requires an
usb-to-uart cable, and<br>
avoids the current SD card
"dance" to run programs on the
Pi.<br>
<br>
Thank you for your time.<br>
<br>
--André Marques<br>
<br>
<br>
</blockquote>
_______________________________________________<br>
rtems-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:rtems-devel@rtems.org"
target="_blank">rtems-devel@rtems.org</a><br>
<a moz-do-not-send="true"
href="http://www.rtems.org/mailman/listinfo/rtems-devel"
target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>
<br>
</blockquote>
_______________________________________________<br>
rtems-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:rtems-devel@rtems.org"
target="_blank">rtems-devel@rtems.org</a><br>
<a moz-do-not-send="true"
href="http://www.rtems.org/mailman/listinfo/rtems-devel"
target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>
</blockquote>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div>
</div>
<div class="">
<pre cols="72">--
Joel Sherrill, Ph.D. Director of Research & Development
<a moz-do-not-send="true" href="mailto:joel.sherrill@OARcorp.com" target="_blank">joel.sherrill@OARcorp.com</a> On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available <a moz-do-not-send="true" href="tel:%28256%29%20722-9985" value="+12567229985" target="_blank">(256) 722-9985</a></pre>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>