potential GSOC project: Improve the Raspberry Pi BSP
Joel Sherrill
joel.sherrill at OARcorp.com
Wed Mar 19 23:04:34 UTC 2014
On 3/19/2014 4:18 PM, Pierre Ficheux wrote:
> Hi Alan,
>
> ----- Mail original -----
>> De: "Alan Cudmore" <alan.cudmore at gmail.com>
>> À: "Pierre Ficheux" <pierre.ficheux at openwide.fr>
>> Cc: "Andre Marques" <andre.lousa.marques at gmail.com>, rtems-users at rtems.org
>> Envoyé: Mercredi 19 Mars 2014 22:10:50
>> Objet: Re: potential GSOC project: Improve the Raspberry Pi BSP
>>
>>
>> Hi Pierre,
>> We hope to use your GPIO implementation for this project. Any
>> problems with incorporating it into the BSP?
> No problem at all.
>
>>
>> For the USB and MMC support, the u-boot code would be nice, but it is
>> GPL and not compatible with the RTEMS libraries. But it could serve
>> as a reference.
> I'm not aware of RTEMS licensing issue :) I know it's GPL with linking exception but what's the problem with "libraries" ?
Ultimately, everything is statically linked together. So the license of
a library
could virally impact the license of all users.
Ideally this support would be part of the BSP.
There is a proposed API and simple driver model for analogs and discrete IO
in RTEMS git in another git module. It includes some shell commands to
assist
in debugging and playing with IO settings.
>>
>> Also, I am not sure how to approach the USB and network
>> implementation. For example, we could probably get the Ethernet to
>> work, and the USB code would just be "a bunch of files" in the
>> ethernet driver directory. But I think the right way would be to use
>> the FreeBSD library support of the USB and Ethernet devices. I just
>> don't know how to do that :)
> I do agree. I talked about U-Boot for MMC support though it includes USB support too.
If this were in the new BSD USB/TCP/IP code, it should be
straightforward to
support both USB and TCP/IP.
> regards
>>
>> Alan
>>
>>
>>
>>
>>
>> On Wed, Mar 19, 2014 at 4:33 PM, Pierre Ficheux <
>> pierre.ficheux at openwide.fr > wrote:
>>
>>
>> USB should be interesting too on RPi because of Ethernet support ;)
>>
>> Regarding SD card you should take a look at U-Boot for RPi which
>> includes MMC support in drivers/mmc. U-Boot includes USB support for
>> RPi too in drivers/usb.
>>
>> https://github.com/gonzoua/u-boot-pi
>>
>> regards
>>
>> ----- Mail original -----
>>> De: "Andre Marques" < andre.lousa.marques at gmail.com >
>>> À: "Alan Cudmore" < alan.cudmore at gmail.com >
>>> Cc: rtems-users at rtems.org
>>> Envoyé: Mercredi 19 Mars 2014 20:59:56
>>> Objet: Re: potential GSOC project: Improve the Raspberry Pi BSP
>>
>>>
>>>
>>> Hello Alan,
>>>
>>> I have decided to go with the framebuffer instead of the USB
>>> support.
>>> Will update the proposal with this.
>>>
>>> Before GSOC I am considering to look at the SD card access through
>>> the onboard card reader. What do you think?
>>>
>>> --André Marques.
>>>
>>> On 03/19/14 00:56, Alan Cudmore wrote:
>>>
>>>
>>>
>>> Hi André ,
>>> I agree about the USB stack. I am not even sure about how to
>>> integrate a driver that depends on the FreeBSD USB stack.
>>>
>>>
>>> The GPIO driver from Pierre is the one I was referring to. I don't
>>> think anyone ever made a decision on how to integrate the GPIO
>>> driver. If we have macros in the BSP header files then the GPIO can
>>> be programmed with the simple macros or the driver that Pierre
>>> wrote. If the project decides to use the GPIO device model for
>>> other
>>> BSPs, then the generic driver code can be moved to a shared
>>> directory at a later date.
>>>
>>>
>>> Thanks for the update,
>>>
>>>
>>> Alan
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Mar 18, 2014 at 11:04 AM, Andre Marques <
>>> andre.lousa.marques at gmail.com > wrote:
>>>
>>>
>>>
>>>
>>> Hello,
>>>
>>> about the USB driver port from FreeBSD I am finding it difficult to
>>> gauge how much work it would involve, so I will follow your
>>> suggestion and look at something else.
>>>
>>> As for GPIO I belive the work that has been done is this:
>>>
>>> https://github.com/pficheux/raspberry_pi/tree/master/RTEMS/gpio_driver
>>>
>>> Am I right?
>>>
>>> I also found a discussion on the best way of implementing the
>>> driver
>>>
>>> http://www.rtems.org/pipermail/rtems-users/2013-October/012059.html
>>>
>>> but i am not sure if that came to a decision.
>>>
>>> Meanwhile I will update the proposal with some basic info on the
>>> drivers.
>>>
>>> --André Marques.
>>>
>>>
>>>
>>> On 03/14/14 13:16, Andre Marques wrote:
>>>
>>>
>>>
>>>
>>>
>>> Hello,
>>>
>>> On 03/14/14 02:33, Alan Cudmore wrote:
>>>
>>>
>>>
>>> Andre,
>>> I think your project proposal looks good, but I wonder if including
>>> USB support is too much. There are low level "bare metal" USB
>>> examples out there for the Raspberry Pi, and that may serve as a
>>> starting point, but I think a real USB implementation will use the
>>> BSD library that has been ported to RTEMS. It may be possible,
>>> since
>>> there is a FreeBSD port to the Raspberry Pi. Maybe others can help
>>> here.
>>>
>>>
>>> I will take a look into this.
>>>
>>>
>>>
>>>
>>>
>>> If you think that GPIO, SPI, and I2C are not enough, then you could
>>> always look at the framebuffer or SD card access.
>>>
>>>
>>> Yes, right now I am trying to clarify everything the best I can so
>>> I
>>> don't end up with a lot more (or less) work than I can handle.
>>>
>>>
>>>
>>>
>>>
>>> Finally, it may be necessary to have an Raspberry Pi and a few
>>> peripherals. For example, I have an inexpensive I2C compass module
>>> that I use with linux, and I have a breadboard wired up with LEDs
>>> to
>>> test GPIO.
>>>
>>>
>>> Right now I have access to a Raspberry Pi at the university, not
>>> sure
>>> about the peripherals though. Anyway, if this projects really goes
>>> forward I will get myself a raspberry and peripherals (I have
>>> already some other components, like a breadboard, leds, wire, etc).
>>>
>>>
>>>
>>>
>>>
>>> Thanks,
>>> Alan
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Mar 13, 2014 at 8:32 PM, Alan Cudmore <
>>> alan.cudmore at gmail.com > wrote:
>>>
>>>
>>>
>>> I'm glad there is interest in this project. Andre, I will read your
>>> proposal and provide feedback.
>>> Joel, I was on the melange site and the system recognizes my
>>> account.
>>> Do I need to do anything to be a mentor for RTEMS?
>>> Alan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Mar 13, 2014 at 7:31 PM, Andre Marques <
>>> andre.lousa.marques at gmail.com > wrote:
>>>
>>>
>>>
>>>
>>> It is now on melange too.
>>>
>>> --André Marques.
>>>
>>>
>>>
>>> On 03/13/14 23:21, Hesham Moustafa wrote:
>>>
>>>
>>>
>>>
>>>
>>> Hi Andre,
>>>
>>>
>>> I quote from RTEMS SoC page :
>>>
>>> "GSOC STUDENTS! PLEASE FILL IN THE APPLICATION AT
>>> http://www.google-melange.com ! YOU CAN EDIT UNTIL THE DEADLINE!
>>> BUT
>>
>>> YOU WILL NOT GET A SLOT IF YOU DO NOT APPLY THROUGH Google!!!"
>>>
>>>
>>> Regards,
>>> Hesham
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Mar 14, 2014 at 1:16 AM, Andre Marques <
>>> andre.lousa.marques at gmail.com > wrote:
>>>
>>>
>>>
>>>
>>> Hello,
>>>
>>> I just posted the first proposal draft for "Raspberry Pi BSP
>>> Peripherals " in the RTEMS Wiki
>>>
>>> http://wiki.rtems.org/wiki/index.php/RTEMSSummerOfCode
>>>
>>> Any feedback is more than welcome. Should I post it already in
>>> melange too?
>>>
>>> --André Marques.
>>>
>>>
>>>
>>> On 03/13/14 15:26, Joel Sherrill wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 3/13/2014 9:46 AM, Andre Marques wrote:
>>>
>>>
>>>
>>> Hello,
>>>
>>> I would be very interested in working in this project because I'm
>>> currently trying to work with Raspberry Pi and RTEMS for my
>>> undergraduate thesis, so this could be a great followup to that for
>>> the summer.
>>>
>>> I will need to do some reseach on it before making a proposal (the
>>> time is also gettting shorter), but will post a proposal draft very
>>> soon.
>>>
>>> This would be a great area to work. As Alan says, the list is
>>> likely
>>> too much for
>>> one student, so it seems likely that the work could be divided for
>>> two students
>>> working on different parts.
>>>
>>> For the Pi Master list, I would like to add the Geert board. That
>>> looks like something
>>> of interest to RTEMS folks.
>>>
>>> --joel
>>>
>>>
>>>
>>>
>>> --André Marques.
>>>
>>> On 03/13/14 11:23, Alan Cudmore wrote:
>>>
>>>
>>>
>>> ( I posted this to the rtems-devel list by mistake, my apologies
>>> for
>>> the duplicate message )
>>>
>>>
>>>
>>> f there are still potential GSOC students out there looking for a
>>> project, I would like to offer a potential project to work on:
>>> Improving the Raspberry Pi BSP. I would be happy to mentor a
>>> student
>>> for this project. Below is my description for the task.
>>>
>>>
>>> Thanks,
>>> Alan
>>>
>>>
>>> One of the RTEMS Open Projects is to contribute a BSP or Board
>>> Support Package for readily available boards. The Raspberry Pi is
>>> probably the most available board at $25 and $35 USD, and there
>>> have
>>> been over two million of these boards sold. The RTEMS head (4.11)
>>> currently has a basic BSP for the Raspberry Pi, supporting the CPU,
>>> a single UART, and timer. It is enough to run some basic RTEMS
>>> programs, but expanding the BSP to support peripherals will make it
>>> much more useful.
>>> For this project, the GSOC student could improve the peripheral
>>> support for the Raspberry Pi BSP.
>>> The peripherals we need to support (in order of increasing
>>> difficulty) include:
>>> 1. GPIO (This has been done by one user, but is not integrated)
>>> 2. I2C Bus
>>> 3. SPI Bus
>>> 4. Secure Digital card read and write support (using the SPI bus)
>>> 5. Graphics / RTEMS Framebuffer Support (I have a graphics demo
>>> working in an RTEMS task)
>>> 6. USB Device support
>>> 7. HDMI/Graphics console (Requires framebuffer support and USB or
>>> GPIO connected keyboard device)
>>> 8. Ethernet network support (Requires USB support)
>>> The entire list is probably too much for a single student to
>>> accomplish, so we can adjust the list of work according to what is
>>> possible.
>>>
>>>
>>> It may also be a good idea to add support for both models of the
>>> Raspberry Pi (256MB and 512MB) and be able to configure the memory
>>> map in the BSP to match the boot time split between the CPU and GPU
>>> memory.
>>>
>>>
>>> Finally, in order to do some of this coding, it may be necessary to
>>> come up with a more efficient way to load and debug code on the
>>> Raspberry Pi. Options include using U-boot or connecting a JTAG
>>> debug device to load code.
>>>
>>>
>>>
>>> _______________________________________________
>>> rtems-users mailing list rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>
>>> --
>>> Joel Sherrill, Ph.D. Director of Research & Development
>>> joel.sherrill at OARcorp.com On-Line Applications Research
>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
>>> Support Available (256) 722-9985
>>>
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>
>> --
>> Pierre FICHEUX -/- CTO OW/OWI, France -\- pierre.ficheux at openwide.fr
>> http://ingenierie.openwide.fr
>> http://www.linuxembedded.fr
>> I would love to change the world, but they won't give me the source
>> code
>>
>>
> --
> Pierre FICHEUX -/- CTO OW/OWI, France -\- pierre.ficheux at openwide.fr
> http://ingenierie.openwide.fr
> http://www.linuxembedded.fr
> I would love to change the world, but they won't give me the source code
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users
mailing list