<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 19:21, Alan Cudmore wrote:<br>
</div>
<blockquote cite="mid:53501BB5.7040702@gmail.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">On 4/17/2014 5:42 AM, Andre Marques
wrote:<br>
</div>
<blockquote cite="mid:534FA208.8000109@gmail.com" type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<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>
</blockquote>
<br>
I agree that the rtems_timer might not be the best mechanism for
the waiting on the mailbox.<br>
If the CPU<->GPU interface supports interrupts, then a
non-blocking driver could be written.<br>
</blockquote>
<br>
From what I understand the CPU<->GPU interface does support
interrupts. <br>
<br>
<blockquote cite="mid:53501BB5.7040702@gmail.com" type="cite">Otherwise,
what is the best approach? <br>
- a sleep call<br>
- polling a status register<br>
<br>
</blockquote>
<br>
Yes a small sleep followed by a polling on the register can be used.<br>
<br>
<blockquote cite="mid:53501BB5.7040702@gmail.com" type="cite"> 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. <br>
<br>
<blockquote cite="mid:534FA208.8000109@gmail.com" type="cite"> <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 moz-do-not-send="true" 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>
Good point. Is this memory barrier an assembly instruction? Should
we create a couple of macros that generate the inline assembly?<br>
<br>
</blockquote>
<br>
It is an assembly instruction:<br>
<br>
<a class="moz-txt-link-freetext" href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/I1014942.html">http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/I1014942.html</a>
(Data memory barrier)<br>
<br>
There is also the need to consider an alternative to the BCM2835_REG
macro (in the raspberrypi.h header) that is being used to access
registers but with the memory barrier calling, instead of calling
the memory barrier macro every time in the code.<br>
<br>
<blockquote cite="mid:53501BB5.7040702@gmail.com" type="cite"> <br>
<br>
<blockquote cite="mid:534FA208.8000109@gmail.com" type="cite">
<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>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>