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