[RTEMS Project] #2891: Beagleboard BSP projects

[RTEMS trac]

#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.

 See ​[http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-
 everything-else-rtems-on-the-beagles.html this blog post] for full
 instructions in building & running the bsp on hardware and in the
 emulator.
 == 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
     I2C
     ADC
     Framebuffer
     USB
     Ethernet
     GPIO
     CAN
     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/>
RTEMS Project