[RTEMS Project] #2891: Beagleboard BSP projects
trac at rtems.org
Tue Jan 31 15:45:09 UTC 2017
#2891: Beagleboard BSP projects
Reporter: tokencolour | Owner: beng
Type: enhancement | Status: new
Priority: normal | Milestone: Indefinite
Component: General | Version: 4.11
Severity: normal | Keywords: GSoC, BSP
== Getting started as a GSOC student ==
If you are interested in working on this BSP as a GSOC project, there are
a few basics you should do immediately, if possible before even asking
about the project, to show that you are up to speed with the basics of
running RTEMS and this BSP in particular.
== You'll need the hardware ==
To test your changes, you will need the relevant hardware. You will also
need a way to see the RTEMS serial console i/o. So, you will need one of
the following, in descending order of advisability if you have the freedom
to choose a model:
* Beaglebone ("white") - this board has everything self-contained (power,
jtag and serial over a single usb cable) so is the ideal board to buy if
you have to choose
* Beaglebone black - this will need a TTL-serial to USB converter cable,
e.g. USB-TTL FTDI Cable 3.3V, and jtag is harder to access so quite
limiting compared to the white. RTEMS does not implement a USB device, so
you can't use a generic usb cable for console i/o.
* Beagleboard XM + serial cable (serial to usb is most convenient - the
ones with the FTDI chip work well)
* Beagleboard + serial cable
== Also build the emulator ==
There is a Beagleboard XM emulator. Run the BSP in that for
* fast iteration, convenient debugging
* testing whether your changes might break the xm and/or the emulator
== Build & run the BSP ==
Build & run the BSP (e.g. using the test set) on whatever you hardware you
have and on the bbxm emulator.
everything-else-rtems-on-the-beagles.html this blog post] for full
instructions in building & running the bsp on hardware and in the
== Make a change in RTEMS ==
To show that you're up to speed with rebuilding RTEMS, make a change.
Showing the result must be part of your proposal.
=== Hello World project ===
The official requirement is a
[https://devel.rtems.org/wiki/GSoC/GettingStarted Hello World project.]
=== Raising the bar ===
Run the test set and debug any of the failing tests, either on the
emulator or on real hardware. One thing to keep in mind is that a failing
test on the emulator could be an imperfection of the emulator.
== Ideas to Improve the BSP ==
The hardware support is rudimentary. This section lists ideas for
improvement of that BSP.
They are listed in no particular order. The biggest factor is motivation -
are you excited to take on the task?
=== Booting without uboot ===
The BSP needs some sort of bootloader to get the app loaded. Currently the
system to do all the work for the user uses uboot. GPL3 is a problem and
so a BSD-licensed alternative to do the same thing would be better.
=== Upstreaming RSB & rtems-tools changes ===
The BSP itself is neatly upstreamed to mainline. There are some changes in
rtems-tools and the RSB that are not neatly in mainline and that is
needed. Coordination with Chris Johns is needed here.
=== Peripheral support ===
There are quite a few missing peripherals. In no particular order
PRU - programmable realtime units, interesting realtime applications
MMC (internal flash & sdcard)
=== Fix failing tests & automatically run tests on future commits ===
On Qemu, most tests pass but not all. On the hardware (running using
JTAG), most tests pass but not all. The reason for them to fail should be
figured out (might be a qemu limitation in the 1st case). Once the tests
are nailed down, coordination with Amar would be good to run these tests
automatically in the qemu linaro so future commits won't break the BSP (or
at least, it will be flagged immediately).
Even better would be to run these tests on hardware automatically of
course, using JTAG. Coordination with Amar/OAR might enable this.
Ticket URL: <http://devel.rtems.org/ticket/2891>
RTEMS Project <http://www.rtems.org/>
More information about the bugs