GSoC Project - Beagle BSP Projects

Ahamed Husni ahamedhusni73 at gmail.com
Fri Apr 2 06:36:54 UTC 2021


>
> >     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.
>> >
>>
>
> I would suggest to put _more_ into the proposal and make it clear that
> the later points depend on whether there is enough time or not.
>
> @Gedare: The time and effort for that project is really hard to estimate
> in my point of view. Do you have an idea how we could handle that?
>

So do I have to include mass storage support into the project schedule or
should I prepare the schedule for Ethernet, Serial  and add the list of
possible advances and say that I'll work on them if there is enough time?



> Most likely we would have to put some further open points at the end of
> that because like I said: Depending on how well it works you might need
> anything between a day and three weeks to get CDC Ethernet running. From
> my first guess, it's maybe a week.
>
> Note that I would expect that you will need a debugger and the RTEMS
> event recording for this kind of project.
>
>
> CDC Serial should be only a small step as soon as CDC Ethernet is running.
>

I don't have a JTAG debugger now. I'll get that set up asap.


>     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
> >     <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'm trying to build and test this branch. I had trouble with building the
libbsd.
So I started to build the tools and kernel from scratch with the RSB
master, using
beaglebone black bset. It gives me the following error.
Error log: https://pastebin.com/NYZRej1B

Build command

> ../source-builder/sb-set-builder --log=beagle.txt --prefix=$BASE/rtems/6
> bsps/beagleboneblack.bset


What would be the steps to configure the USB OTG driver from libbsd to BBB.
I would like to try it out. Please guide me on this.

Best regards,

On Fri, Mar 26, 2021 at 8:17 PM Christian MAUDERER <
christian.mauderer at embedded-brains.de> wrote:

> Hello Ahamed,
>
> Am 26.03.21 um 15:31 schrieb Ahamed Husni:
> >     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
> >     <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?
>
> Most likely we would have to put some further open points at the end of
> that because like I said: Depending on how well it works you might need
> anything between a day and three weeks to get CDC Ethernet running. From
> my first guess, it's maybe a week.
>
> Note that I would expect that you will need a debugger and the RTEMS
> event recording for this kind of project.
>
>
> CDC Serial should be only a small step as soon as CDC Ethernet is running.
>
> Mass storage depends on the current implementation for that in FreeBSD.
> It might could be an interesting part.
>
> >
> > Would implementing Ethernet and Serial solve the problem of using TTL
> > converters
> > when working on RTEMS in Beagle for the developers?
> >
>
> Depends on the application. For those who want to write an application,
> a CDC Serial device would be a nice alternative. For those who want to
> develop drivers or RTEMS itself: Very unlikely that CDC Serial is enough
> for that.
>
> >     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.
> >
>
> I would suggest to put _more_ into the proposal and make it clear that
> the later points depend on whether there is enough time or not.
>
> @Gedare: The time and effort for that project is really hard to estimate
> in my point of view. Do you have an idea how we could handle that?
>
>
> >
> >     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?
>
> I expect a JTAG-Debugger. I had good experience with the Segger J-Link
> EDU for GSoC projects with BBB. Alternatively there are OpenOCD based
> ones out there too that are said do work well. Note that you have to
> solder a debug connector to the Beagle for that.
>
> Best regards
>
> Christian
>
> >
> > Regards,
> > Husni.
> >
> > On Tue, Mar 23, 2021 at 10:25 PM Utkarsh Rai <utkarsh.rai60 at gmail.com
> > <mailto:utkarsh.rai60 at gmail.com>> wrote:
> >
> >
> >
> >
> >     On Tue, Mar 23, 2021 at 9:36 PM Nils Hölscher <nilhoel1 at gmail.com
> >     <mailto: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
> >         <mailto: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
> >             <mailto: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
> >             <https://devel.rtems.org/ticket/2891>>]. *
> >              >>> *
> >              >>> *Adding PRU Support* [#3730
> >             <https://devel.rtems.org/ticket/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
> >             <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/2019-December/056478.html>
> >              >
> >
> https://lists.rtems.org/pipermail/devel/2020-January/056958.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
> >             <
> 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
> >             <
> 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 <mailto:devel at rtems.org>
> >              >>> http://lists.rtems.org/mailman/listinfo/devel
> >             <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
> >             <mailto: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/
> >             <https://embedded-brains.de/datenschutzerklaerung/>
> >              >> _______________________________________________
> >              >> devel mailing list
> >              >> devel at rtems.org <mailto:devel at rtems.org>
> >              >> http://lists.rtems.org/mailman/listinfo/devel
> >             <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
> >             <mailto: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/
> >             <https://embedded-brains.de/datenschutzerklaerung/>
> >
>
> --
> --------------------------------------------
> 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/
>


-- 
Husni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210402/b4ea6695/attachment-0003.html>


More information about the devel mailing list