GSoC Project - Beagle BSP Projects
Ahamed Husni
ahamedhusni73 at gmail.com
Fri Apr 9 14:28:05 UTC 2021
Hi all,
I have prepared a draft proposal
<https://docs.google.com/document/d/1CN3ri7g6NJeFPb5h8y4smr1aziGWyXbiiXUsFMhdUu4/edit?usp=sharing>.
Added the proposal link to RTEMS Wiki.
Husni Faiz - https://devel.rtems.org/wiki/GSoC/2021
Please have a look and let me know your thoughts.
The project description is not complete yet.
I submitted the draft to GSoC as well.
Best regards,
Husni Faiz.
On Fri, Apr 2, 2021 at 6:16 PM Christian Mauderer <oss at c-mauderer.de> wrote:
>
>
> On 02/04/2021 08:36, Ahamed Husni wrote:
> > > 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?
>
> I would suggest to include it. I'm quite sure that 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>
> > >
> > <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.
>
> The branch is very old. Most likely it won't build with a current
> toolchain and a current RTEMS. You might want to try to rebase the last
> two patches onto an up to date 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 <https://pastebin.com/NYZRej1B>
> >
> > Build command
> >
> > ../source-builder/sb-set-builder --log=beagle.txt
> > --prefix=$BASE/rtems/6 bsps/beagleboneblack.bset
>
> For development I would suggest to build only the toolchain using RSB.
> After that you should build the BSP and libbsd manually. You will have
> to recompile the BSP and libbsd quite often and it's a lot more
> convenient to do that without touching RSB every time.
>
> I would suggest to use some simple scripts or a Makefile for that.
> Something like
>
> https://gitlab.com/c-mauderer/rtems-bbb/-/blob/master/Makefile
>
> Note that the repo containing that Makefile is no official one and it is
> unstable. Most of the time I use it for testing stuff.
>
> >
> > 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.
>
> I think that's most of the problem of the GSoC ;-)
>
> Basically it's the following steps:
>
> - Importing the relevant parts (should be the usb_template stuff) from
> FreeBSD into libbsd. That's basically what the first commit on the
> branch does. Take a look at the CONTRIBUTING.md file in libbsd for
> details about the import process:
> https://git.rtems.org/rtems-libbsd/tree/CONTRIBUTING.md#n158
>
> - Enable them for Beagle. That's the second commit on the branch.
>
> - Somehow configure the USB OTG stuff. Like I said: That's the tricky
> part. It has something to do with the usb_temp_init functions. But I
> didn't manage to get it working in an hour or so and stopped trying
> after that. So finding out how to configure and set up the stuff will be
> part of your Project.
>
> Best regards
>
> Christian
>
> >
> > Best regards,
> >
> > On Fri, Mar 26, 2021 at 8:17 PM Christian MAUDERER
> > <christian.mauderer at embedded-brains.de
> > <mailto: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>
> > >
> > <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>
> > > <mailto: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>
> > > <mailto: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>
> > > <mailto: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>
> > > <mailto: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>
> > > <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>
> > > <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>
> > > <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/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>
> > >
> > <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>
> > >
> > <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
> >
> > >
> > <
> 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>
> > <mailto:devel at rtems.org <mailto:devel at rtems.org>>
> > > >>> http://lists.rtems.org/mailman/listinfo/devel
> > <http://lists.rtems.org/mailman/listinfo/devel>
> > > <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>
> > > <mailto: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/>
> > > <https://embedded-brains.de/datenschutzerklaerung/
> > <https://embedded-brains.de/datenschutzerklaerung/>>
> > > >> _______________________________________________
> > > >> devel mailing list
> > > >> devel at rtems.org <mailto:devel at rtems.org>
> > <mailto:devel at rtems.org <mailto:devel at rtems.org>>
> > > >> http://lists.rtems.org/mailman/listinfo/devel
> > <http://lists.rtems.org/mailman/listinfo/devel>
> > > <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>
> > > <mailto: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/>
> > > <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
> > <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/>
> >
> >
> >
> > --
> > Husni
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210409/b886e112/attachment-0001.html>
More information about the devel
mailing list