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 <o...@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.maude...@embedded-brains.de > > <mailto:christian.maude...@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.ra...@gmail.com <mailto:utkarsh.ra...@gmail.com> > > > <mailto:utkarsh.ra...@gmail.com > > <mailto:utkarsh.ra...@gmail.com>>> wrote: > > > > > > > > > > > > > > > On Tue, Mar 23, 2021 at 9:36 PM Nils Hölscher > > <nilho...@gmail.com <mailto:nilho...@gmail.com> > > > <mailto:nilho...@gmail.com <mailto:nilho...@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.maude...@embedded-brains.de > > <mailto:christian.maude...@embedded-brains.de> > > > <mailto:christian.maude...@embedded-brains.de > > <mailto:christian.maude...@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.maude...@embedded-brains.de > > <mailto:christian.maude...@embedded-brains.de> > > > <mailto:christian.maude...@embedded-brains.de > > <mailto:christian.maude...@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@rtems.org <mailto:devel@rtems.org> > > <mailto:devel@rtems.org <mailto:devel@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.maude...@embedded-brains.de > > <mailto:christian.maude...@embedded-brains.de> > > > <mailto:christian.maude...@embedded-brains.de > > <mailto:christian.maude...@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@rtems.org <mailto:devel@rtems.org> > > <mailto:devel@rtems.org <mailto:devel@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.maude...@embedded-brains.de > > <mailto:christian.maude...@embedded-brains.de> > > > <mailto:christian.maude...@embedded-brains.de > > <mailto:christian.maude...@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.maude...@embedded-brains.de > > <mailto:christian.maude...@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@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
