GSOC 2017 BeagleBone BSP project

[Gedare Bloom]

On Sun, Mar 12, 2017 at 9:48 AM, Piotr Sykulski <pitersk at gmail.com> wrote:
> Hello,
>
> My name is Piotr Sykulski and I'm a student from Poland. I would like to
> contribute to the RTEMS project by participating in Google Summer of Code
> 2017. I already completed the Hello world project describe here
> https://devel.rtems.org/wiki/TBR/UserManual/Quick_Start . Where and how
> should I submit the proof?
>
Please send directly to me by e-mail.

> I'm interested in adding support for peripherals like I2C, ADC, PRU, etc.
> I've found blog of the student who succesfully  developed PWM support and
> started working on I2C
> https://learnsom2day.wordpress.com/2016/08/23/gsoc-2016-improvement-of-board-support-package-for-beagle-bone-black/
> . I could pick up from where he left and start working on I2C first. Other
> than that I would be really interested in PRUs or ADCs, but I think it is
> really up to the mentors to say what's needed first. So I am asking for help
> in choosing project subjects and writing the proposal.
>
BB projects are good, but I'm not sure what is left that is of a high
priority. Hopefully some of the past BB folks will make suggestions.
One area that might be worthwhile is getting the current libbsd
version working. You should show confirmation that you can run the BB
BSP on your hardware for a good pre-proposal activity.

There is probably sufficient work and interest to get RTEMS to operate
the PRU, either as a "peripheral" or as a standalone RTEMS image. I'm
not sure what is involved there. I'm sure the other BB devs will have
a better idea.

Adding 1-off support for random peripherals is not a satisfying GSoC
project. There should be some additional thought in terms of
integrating the BSP with existing device driver frameworks or
importing/creating new device driver frameworks for peripherals that
are not available in RTEMS. For example, I don't think we have an
ADC/DAC framework. A good design is important for such a project, and
so is researching what are available in other open-source OS and
libraries. If nothing is suitable, it is appropriate to design one,
but you need to do a lot of work in the proposal phase to ensure a
good, productive SoC. For more guidance, you should try to reach out
to Andre Marques who did a GPIO framework as an SoC project.

We strongly prefer that each student select and propose projects based
on individual interests, preference, and capability. For actual
proposal writing, adapt the template we provide (you need to make
several adjustments to it) and leverage the tips and resources in the
GSoC Student Manual
http://write.flossmanuals.net/gsocstudentguide/what-is-google-summer-of-code/

> One problem is that I can't find any vendor selling Beaglebone White boards.
> I can easily find Black boards, but as it is described on project site you
> can't debug with jtag there. Do you think that debugging using serial port
> would be enough for these projects?
>
You can debug BBB with JTAG, but as I understand it you need to solder
on an adapter bit of hardware.

Debugging with serial port is fine for the most part if stepping
through the code is not important. For small pieces of code this isn't
so big of a deal, but if you work with a large integration project
(such as libbsd or testing kernel modifications with BB), then the
JTAG becomes more important.

> I was also interested in adding support for Raspberry Pi, but there is no
> mentor listed under this project so I'm not sure it is active, could someone
> clarify that for me?
>
There are mentors available for the RPi, and a clearer description of
work available for this summer available on that ticket. As with BB,
you should demonstrate you can run RTEMS on the board during the
pre-proposal phase.

> Best regards,
> Piotr Sykulski
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users