GSoC Project - Beagle BSP Projects

Ahamed Husni ahamedhusni73 at gmail.com
Fri Mar 26 14:31:17 UTC 2021 

>
> USB OTG would be a nice area. But that will be less writing a driver for
> Beagle but more finding out how that works with libbsd and finding a
> good way to configure it. I once put a few hours into it didn't take too
> much time till a PC detected an USB device (see
> https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce).
> Basically it's about importing the "usb_template" stuff and finding a
> way to configure it in libbsd.
>
> I think that topic would have to be a bit of an open one: You might work
> only a day on it and have a working CDC Ethernet afterwards or you can
> need weeks for that. So you should add an open list of possible advanced
> targets. An OTG device can be:
>
> - Ethernet
> - Serial port
> - Mass storage
> - Keyboard / Mouse
> - Modem
> - Audio
> - ...
>
> The simplest one will most likely be Ethernet followed by serial port. I
> would add some of the others (like mass storage) as an extended targets.
>
> Best regards
>
> Christian


USB OTG would allow more extended capabilities for the beagle board.
To work on the USB OTG devices, what would be the best way?
What I understood from what Christian says is,

   1. Finding out how USB OTG works with libbsd and finding a
    way to configure it for the beagle.
   2. Work on CDC Ethernet
   3. CDC Ethernet - Example application & Documentation
   4. Work on Serial over USB
   5. Serial over USB - Example application & Documentation

Am I right?

Would implementing Ethernet and Serial solve the problem of using TTL
converters
when working on RTEMS in Beagle for the developers?

Yes, this seems like an area that can be chipped away at, with a
> strong plan of activities. My concern would be whether it is about
> writing code or not?
>

After completing the above milestones, if we have more time I can start to
work on
the Mass storage support.



> Hi,
>
> Regarding the PRU.
> I was able to load code to the PRU.
> However I wasn't able to map IRQ interrupts to the PRU, thus unable to
> communicate with it in a meaningful way.
> Also I don't think that this project should be continued without a full
> DEBUGGING Setup.
>
> Best,
> Nils
>

+1, without a proper debugging setup I found it hard to precisely pin point
> the problem when I initially took up this task.
>

What is the full DEBUGGING setup needed to work on the PRU?

Regards,
Husni.

On Tue, Mar 23, 2021 at 10:25 PM Utkarsh Rai <utkarsh.rai60 at gmail.com>
wrote:

>
>
>
> On Tue, Mar 23, 2021 at 9:36 PM Nils Hölscher <nilhoel1 at gmail.com> wrote:
>
>> Hi,
>>
>> Regarding the PRU.
>> I was able to load code to the PRU.
>> However I wasn't able to map IRQ interrupts to the PRU, thus unable to
>> communicate with it in a meaningful way
>>
>
>
> Just a small addition, AFAIK the issue with this was the fact that mmap()
> would always fail.
>
>
>> .
>> Also I don't think that this project should be continued without a full
>> DEBUGGING Setup.
>>
>
> +1, without a proper debugging setup I found it hard to precisely pin
> point the problem when I initially took up this task.
>
>
>>
>>
> Best,
>> Nils
>>
>> On Tue, 23 Mar 2021 at 17:00, Christian MAUDERER <
>> christian.mauderer at embedded-brains.de> wrote:
>>
>>> Hello Gedare,
>>>
>>> Am 23.03.21 um 16:48 schrieb Gedare Bloom:
>>> > CC: Nils, Utkarsh
>>> >
>>> > On Tue, Mar 23, 2021 at 9:17 AM Christian MAUDERER
>>> > <christian.mauderer at embedded-brains.de> wrote:
>>> >>
>>> >> Hello Ahamed,
>>> >>
>>> >> Am 23.03.21 um 11:24 schrieb Ahamed Husni:
>>> >>> Hi everyone,
>>> >>>
>>> >>> I'm really interested to work on the *Beagle BSP Projects* [#2891
>>> >>> <https://devel.rtems.org/ticket/2891>]. *
>>> >>> *
>>> >>> *Adding PRU Support* [#3730 <https://devel.rtems.org/ticket/3730>]
>>> >>> project seems really interesting to me.
>>> >>> This project is partially done during GSoC 2019
>>> >>> <https://devel.rtems.org/wiki/GSoC/2019>by Nils Hölscher .
>>> >>> Is this a good project for the GSoC?
>>> >>>
>>> >>> Up to now I have,
>>> >>>
>>> >>>   1. Completed the GSoC prerequisite task
>>> >>>   2. Got the required hardware and tested it. (Beagleboard Black,
>>> USB to
>>> >>>      TTL Converter)
>>> >>>   3. Installed RTEMS on the Beagleboard and tested. (Screenshot
>>> attached
>>> >>>      below)
>>> >>>
>>> >>>
>>> >>> I need guidance to define the scope of the project.
>>> >>> I'm currently thinking of ,
>>> >>>
>>> >>>   1. First finish the remaining work from GSoC 2019 on the PRU.
>>> >>>      (What is the status of current implementation of the PRU?)
>>> >>
>>> >> I'm really not sure what the state of the PRU is. I didn't follow that
>>> >> project closely. Maybe one of the mentors of that project can say
>>> >> anything regarding that.
>>> >>
>>> > Some more background:
>>> > https://lists.rtems.org/pipermail/devel/2019-December/056478.html
>>> > https://lists.rtems.org/pipermail/devel/2020-January/056958.html
>>> >
>>> > Maybe Utkarsh or Nils have more to say.
>>> >
>>> >>>   2. Implement additional peripheral support.
>>> >>>      What would be most useful?
>>> >>>      (USB OTG, CAN, ...).
>>> >>
>>> >> I think CAN is a bit hard without some CAN analyzer hardware as a
>>> peer.
>>> >>
>>> >> USB OTG would be a nice area. But that will be less writing a driver
>>> for
>>> >> Beagle but more finding out how that works with libbsd and finding a
>>> >> good way to configure it. I once put a few hours into it didn't take
>>> too
>>> >> much time till a PC detected an USB device (see
>>> >> https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce).
>>> >> Basically it's about importing the "usb_template" stuff and finding a
>>> >> way to configure it in libbsd.
>>> >>
>>> >> I think that topic would have to be a bit of an open one: You might
>>> work
>>> >> only a day on it and have a working CDC Ethernet afterwards or you can
>>> >> need weeks for that. So you should add an open list of possible
>>> advanced
>>> >> targets. An OTG device can be:
>>> >>
>>> >> - Ethernet
>>> >> - Serial port
>>> >> - Mass storage
>>> >> - Keyboard / Mouse
>>> >> - Modem
>>> >> - Audio
>>> >> - ...
>>> >>
>>> >> The simplest one will most likely be Ethernet followed by serial
>>> port. I
>>> >> would add some of the others (like mass storage) as an extended
>>> targets.
>>> >>
>>> > Yes, this seems like an area that can be chipped away at, with a
>>> > strong plan of activities. My concern would be whether it is about
>>> > writing code or not?
>>> >
>>>
>>> It won't produce a lot of code. But it will produce relevant one:
>>>
>>> 1. Interface for configuration (if necessary)
>>>
>>> 2. Example application
>>>
>>> 3. Documentation
>>>
>>> For Ethernet and serial port that's most likely it. For Mass storage
>>> there might be some more code. Without a too detailed look: I would
>>> expect that the mass storage either implements some access to a raw
>>> block device - in which case it would be necessary to add the access to
>>> block devices. Or it implements something like the PTP stuff used on
>>> smartphones in which case there will be most likely some code that
>>> accesses the file system using POSIX functions instead of FreeBSD kernel
>>> functions.
>>>
>>> Best regards
>>>
>>> Christian
>>>
>>> >> Best regards
>>> >>
>>> >> Christian
>>> >>
>>> >>>
>>> >>>      The builtin USB is NOT functional other than for power under
>>> RTEMS.
>>> >>>      (USB OTG would have to be implemented in RTEMS to get rid of
>>> USB to
>>> >>>      TTL Converter.)
>>> >>>      - Ben Gras
>>> >>>      <
>>> http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html
>>> >
>>> >>>      (Blog post)
>>> >>>
>>> >>>
>>> >>> Thanks,
>>> >>> Husni Faiz.
>>> >>>
>>> >>>
>>> >>> BBB_Serial_Out.png
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> devel mailing list
>>> >>> devel at rtems.org
>>> >>> http://lists.rtems.org/mailman/listinfo/devel
>>> >>>
>>> >>
>>> >> --
>>> >> --------------------------------------------
>>> >> embedded brains GmbH
>>> >> Herr Christian MAUDERER
>>> >> Dornierstr. 4
>>> >> 82178 Puchheim
>>> >> Germany
>>> >> email: christian.mauderer at embedded-brains.de
>>> >> phone: +49-89-18 94 741 - 18
>>> >> fax:   +49-89-18 94 741 - 08
>>> >>
>>> >> Registergericht: Amtsgericht München
>>> >> Registernummer: HRB 157899
>>> >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas
>>> Dörfler
>>> >> Unsere Datenschutzerklärung finden Sie hier:
>>> >> https://embedded-brains.de/datenschutzerklaerung/
>>> >> _______________________________________________
>>> >> devel mailing list
>>> >> devel at rtems.org
>>> >> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>> --
>>> --------------------------------------------
>>> embedded brains GmbH
>>> Herr Christian MAUDERER
>>> Dornierstr. 4
>>> 82178 Puchheim
>>> Germany
>>> email: christian.mauderer at embedded-brains.de
>>> phone: +49-89-18 94 741 - 18
>>> fax:   +49-89-18 94 741 - 08
>>>
>>> Registergericht: Amtsgericht München
>>> Registernummer: HRB 157899
>>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>>> Unsere Datenschutzerklärung finden Sie hier:
>>> https://embedded-brains.de/datenschutzerklaerung/
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210326/81e035d4/attachment-0001.html>

More information about the devel mailing list