GSoC Project - Beagle BSP Projects
Christian MAUDERER
christian.mauderer at embedded-brains.de
Fri Mar 26 14:46:57 UTC 2021
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/
More information about the devel
mailing list