GSoC Project - Beagle BSP Projects

Tue Mar 23 16:54:50 UTC 2021

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/20210323/69426c37/attachment.html>