> > > 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.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>). > > 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>> wrote: > > > > > > > > > > On Tue, Mar 23, 2021 at 9:36 PM Nils Hölscher <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>> 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>> 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@rtems.org <mailto:devel@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.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/> > > >> _______________________________________________ > > >> devel mailing list > > >> devel@rtems.org <mailto:devel@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.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/> > > > > -- > -------------------------------------------- > embedded brains GmbH > Herr Christian MAUDERER > Dornierstr. 4 > 82178 Puchheim > Germany > email: 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/ > -- Husni
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel