<div dir="ltr">Hi all,<br><div><br></div><div><div>My project proposal<br><a href="https://docs.google.com/document/d/1CN3ri7g6NJeFPb5h8y4smr1aziGWyXbiiXUsFMhdUu4/edit?usp=sharing">https://docs.google.com/document/d/1CN3ri7g6NJeFPb5h8y4smr1aziGWyXbiiXUsFMhdUu4/edit?usp=sharing</a></div></div><div><br></div>I tried to set up the JTAG Environment for the Beaglebone Black.<br><div>But I couldn't find the hardware anywhere in my country (Sri Lanka).</div><div><br></div><div>I tried to,<br></div><div><ol><li>Find TI XDS Debuggers</li><li>Find a TI Launchpad so we can isolate and use the debugger in it.<br></li><li>Use RPi as a debugger using OpenOCD</li></ol>I looked for the debuggers in major electronic shops, embedded systems related companies,</div><div>university labs and etc. But couldn't find them.<br></div><div>Also these debuggers are expensive. When ordering online the shipping charges are also high.</div><div>So I can't guarantee that I can set up JTAG.</div><div><br></div><div>Can we use RTEMS Libdebugger until we figure out the JTAG?</div><div>Can we make a fallback plan for this project? If yes, what sorts of changes should be made?<br></div><div><br></div><div>Best regards,</div><div>Husni.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 2, 2021 at 6:16 PM Christian Mauderer <<a href="mailto:oss@c-mauderer.de">oss@c-mauderer.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 02/04/2021 08:36, Ahamed Husni wrote:<br>
>         >     Yes, this seems like an area that can be chipped away at, with a<br>
>         >     strong plan of activities. My concern would be whether it is about<br>
>         >     writing code or not?<br>
>         > <br>
>         > <br>
>         > After completing the above milestones, if we have more time I can start <br>
>         > to work on<br>
>         > the Mass storage support.<br>
>         ><br>
> <br>
> <br>
>     I would suggest to put _more_ into the proposal and make it clear that<br>
>     the later points depend on whether there is enough time or not.<br>
> <br>
>     @Gedare: The time and effort for that project is really hard to<br>
>     estimate<br>
>     in my point of view. Do you have an idea how we could handle that?<br>
> <br>
> <br>
> So do I have to include mass storage support into the project schedule or<br>
> should I prepare the schedule for Ethernet, Serial and add the list of<br>
> possible advances and say that I'll work on them if there is enough time?<br>
<br>
I would suggest to include it. I'm quite sure that there is enough time.<br>
<br>
> <br>
>     Most likely we would have to put some further open points at the end of<br>
>     that because like I said: Depending on how well it works you might need<br>
>     anything between a day and three weeks to get CDC Ethernet running.<br>
>      From<br>
>     my first guess, it's maybe a week.<br>
> <br>
>     Note that I would expect that you will need a debugger and the RTEMS<br>
>     event recording for this kind of project.<br>
> <br>
> <br>
>     CDC Serial should be only a small step as soon as CDC Ethernet is<br>
>     running.<br>
> <br>
> <br>
> I don't have a JTAG debugger now. I'll get that set up asap.<br>
> <br>
> <br>
>     >     USB OTG would be a nice area. But that will be less writing a driver<br>
>     >     for<br>
>     >     Beagle but more finding out how that works with libbsd and finding a<br>
>     >     good way to configure it. I once put a few hours into it didn't take<br>
>     >     too<br>
>     >     much time till a PC detected an USB device (see<br>
>     >     <a href="https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce" rel="noreferrer" target="_blank">https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce</a><br>
>     <<a href="https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce" rel="noreferrer" target="_blank">https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce</a>><br>
>      >   <br>
>       <<a href="https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce" rel="noreferrer" target="_blank">https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce</a><br>
>     <<a href="https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce" rel="noreferrer" target="_blank">https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce</a>>>).<br>
>     >     Basically it's about importing the "usb_template" stuff and finding a<br>
>     >     way to configure it in libbsd.<br>
> <br>
> <br>
> I'm trying to build and test this branch. I had trouble with building <br>
> the libbsd.<br>
<br>
The branch is very old. Most likely it won't build with a current <br>
toolchain and a current RTEMS. You might want to try to rebase the last <br>
two patches onto an up to date libbsd.<br>
<br>
> So I started to build the tools and kernel from scratch with the RSB <br>
> master, using<br>
> beaglebone black bset. It gives me the following error.<br>
> Error log: <a href="https://pastebin.com/NYZRej1B" rel="noreferrer" target="_blank">https://pastebin.com/NYZRej1B</a> <<a href="https://pastebin.com/NYZRej1B" rel="noreferrer" target="_blank">https://pastebin.com/NYZRej1B</a>><br>
> <br>
> Build command<br>
> <br>
>     ../source-builder/sb-set-builder --log=beagle.txt<br>
>     --prefix=$BASE/rtems/6 bsps/beagleboneblack.bset<br>
<br>
For development I would suggest to build only the toolchain using RSB. <br>
After that you should build the BSP and libbsd manually. You will have <br>
to recompile the BSP and libbsd quite often and it's a lot more <br>
convenient to do that without touching RSB every time.<br>
<br>
I would suggest to use some simple scripts or a Makefile for that. <br>
Something like<br>
<br>
     <a href="https://gitlab.com/c-mauderer/rtems-bbb/-/blob/master/Makefile" rel="noreferrer" target="_blank">https://gitlab.com/c-mauderer/rtems-bbb/-/blob/master/Makefile</a><br>
<br>
Note that the repo containing that Makefile is no official one and it is <br>
unstable. Most of the time I use it for testing stuff.<br>
<br>
> <br>
> What would be the steps to configure the USB OTG driver from libbsd to BBB.<br>
> I would like to try it out. Please guide me on this.<br>
<br>
I think that's most of the problem of the GSoC ;-)<br>
<br>
Basically it's the following steps:<br>
<br>
- Importing the relevant parts (should be the usb_template stuff) from <br>
FreeBSD into libbsd. That's basically what the first commit on the <br>
branch does. Take a look at the CONTRIBUTING.md file in libbsd for <br>
details about the import process: <br>
<a href="https://git.rtems.org/rtems-libbsd/tree/CONTRIBUTING.md#n158" rel="noreferrer" target="_blank">https://git.rtems.org/rtems-libbsd/tree/CONTRIBUTING.md#n158</a><br>
<br>
- Enable them for Beagle. That's the second commit on the branch.<br>
<br>
- Somehow configure the USB OTG stuff. Like I said: That's the tricky <br>
part. It has something to do with the usb_temp_init functions. But I <br>
didn't manage to get it working in an hour or so and stopped trying <br>
after that. So finding out how to configure and set up the stuff will be <br>
part of your Project.<br>
<br>
Best regards<br>
<br>
Christian<br>
<br>
> <br>
> Best regards,<br>
> <br>
> On Fri, Mar 26, 2021 at 8:17 PM Christian MAUDERER <br>
> <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a> <br>
> <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>>> wrote:<br>
> <br>
>     Hello Ahamed,<br>
> <br>
>     Am 26.03.21 um 15:31 schrieb Ahamed Husni:<br>
>      >     USB OTG would be a nice area. But that will be less writing a<br>
>     driver<br>
>      >     for<br>
>      >     Beagle but more finding out how that works with libbsd and<br>
>     finding a<br>
>      >     good way to configure it. I once put a few hours into it<br>
>     didn't take<br>
>      >     too<br>
>      >     much time till a PC detected an USB device (see<br>
>      > <a href="https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce" rel="noreferrer" target="_blank">https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce</a><br>
>     <<a href="https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce" rel="noreferrer" target="_blank">https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce</a>><br>
>      >   <br>
>       <<a href="https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce" rel="noreferrer" target="_blank">https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce</a><br>
>     <<a href="https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce" rel="noreferrer" target="_blank">https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce</a>>>).<br>
>      >     Basically it's about importing the "usb_template" stuff and<br>
>     finding a<br>
>      >     way to configure it in libbsd.<br>
>      ><br>
>      >     I think that topic would have to be a bit of an open one: You<br>
>     might<br>
>      >     work<br>
>      >     only a day on it and have a working CDC Ethernet afterwards<br>
>     or you can<br>
>      >     need weeks for that. So you should add an open list of possible<br>
>      >     advanced<br>
>      >     targets. An OTG device can be:<br>
>      ><br>
>      >     - Ethernet<br>
>      >     - Serial port<br>
>      >     - Mass storage<br>
>      >     - Keyboard / Mouse<br>
>      >     - Modem<br>
>      >     - Audio<br>
>      >     - ...<br>
>      ><br>
>      >     The simplest one will most likely be Ethernet followed by serial<br>
>      >     port. I<br>
>      >     would add some of the others (like mass storage) as an<br>
>     extended targets.<br>
>      ><br>
>      >     Best regards<br>
>      ><br>
>      >     Christian<br>
>      ><br>
>      ><br>
>      > USB OTG would allow more extended capabilities for the beagle board.<br>
>      > To work on the USB OTG devices, what would be the best way?<br>
>      > What I understood from what Christian says is,<br>
>      ><br>
>      >  1. Finding out how USB OTG works with libbsd and finding a<br>
>      >       way to configure it for the beagle.<br>
>      >  2. Work on CDC Ethernet<br>
>      >  3. CDC Ethernet - Example application & Documentation<br>
>      >  4. Work on Serial over USB<br>
>      >  5. Serial over USB - Example application & Documentation<br>
>      ><br>
>      > Am I right?<br>
> <br>
>     Most likely we would have to put some further open points at the end of<br>
>     that because like I said: Depending on how well it works you might need<br>
>     anything between a day and three weeks to get CDC Ethernet running.<br>
>      From<br>
>     my first guess, it's maybe a week.<br>
> <br>
>     Note that I would expect that you will need a debugger and the RTEMS<br>
>     event recording for this kind of project.<br>
> <br>
> <br>
>     CDC Serial should be only a small step as soon as CDC Ethernet is<br>
>     running.<br>
> <br>
>     Mass storage depends on the current implementation for that in FreeBSD.<br>
>     It might could be an interesting part.<br>
> <br>
>      ><br>
>      > Would implementing Ethernet and Serial solve the problem of using<br>
>     TTL<br>
>      > converters<br>
>      > when working on RTEMS in Beagle for the developers?<br>
>      ><br>
> <br>
>     Depends on the application. For those who want to write an application,<br>
>     a CDC Serial device would be a nice alternative. For those who want to<br>
>     develop drivers or RTEMS itself: Very unlikely that CDC Serial is<br>
>     enough<br>
>     for that.<br>
> <br>
>      >     Yes, this seems like an area that can be chipped away at, with a<br>
>      >     strong plan of activities. My concern would be whether it is<br>
>     about<br>
>      >     writing code or not?<br>
>      ><br>
>      ><br>
>      > After completing the above milestones, if we have more time I can<br>
>     start<br>
>      > to work on<br>
>      > the Mass storage support.<br>
>      ><br>
> <br>
>     I would suggest to put _more_ into the proposal and make it clear that<br>
>     the later points depend on whether there is enough time or not.<br>
> <br>
>     @Gedare: The time and effort for that project is really hard to<br>
>     estimate<br>
>     in my point of view. Do you have an idea how we could handle that?<br>
> <br>
> <br>
>      ><br>
>      >     Hi,<br>
>      ><br>
>      >     Regarding the PRU.<br>
>      >     I was able to load code to the PRU.<br>
>      >     However I wasn't able to map IRQ interrupts to the PRU, thus<br>
>     unable<br>
>      >     to communicate with it in a meaningful way.<br>
>      >     Also I don't think that this project should be continued<br>
>     without a<br>
>      >     full DEBUGGING Setup.<br>
>      ><br>
>      >     Best,<br>
>      >     Nils<br>
>      ><br>
>      ><br>
>      >     +1, without a proper debugging setup I found it hard to precisely<br>
>      >     pin point the problem when I initially took up this task.<br>
>      ><br>
>      ><br>
>      > What is the full DEBUGGING setup needed to work on the PRU?<br>
> <br>
>     I expect a JTAG-Debugger. I had good experience with the Segger J-Link<br>
>     EDU for GSoC projects with BBB. Alternatively there are OpenOCD based<br>
>     ones out there too that are said do work well. Note that you have to<br>
>     solder a debug connector to the Beagle for that.<br>
> <br>
>     Best regards<br>
> <br>
>     Christian<br>
> <br>
>      ><br>
>      > Regards,<br>
>      > Husni.<br>
>      ><br>
>      > On Tue, Mar 23, 2021 at 10:25 PM Utkarsh Rai<br>
>     <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a> <mailto:<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>><br>
>      > <mailto:<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a><br>
>     <mailto:<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>>>> wrote:<br>
>      ><br>
>      ><br>
>      ><br>
>      ><br>
>      >     On Tue, Mar 23, 2021 at 9:36 PM Nils Hölscher<br>
>     <<a href="mailto:nilhoel1@gmail.com" target="_blank">nilhoel1@gmail.com</a> <mailto:<a href="mailto:nilhoel1@gmail.com" target="_blank">nilhoel1@gmail.com</a>><br>
>      >     <mailto:<a href="mailto:nilhoel1@gmail.com" target="_blank">nilhoel1@gmail.com</a> <mailto:<a href="mailto:nilhoel1@gmail.com" target="_blank">nilhoel1@gmail.com</a>>>> wrote:<br>
>      ><br>
>      >         Hi,<br>
>      ><br>
>      >         Regarding the PRU.<br>
>      >         I was able to load code to the PRU.<br>
>      >         However I wasn't able to map IRQ interrupts to the PRU, thus<br>
>      >         unable to communicate with it in a meaningful way<br>
>      ><br>
>      ><br>
>      ><br>
>      >     Just a small addition, AFAIK the issue with this was the fact<br>
>     that<br>
>      >     mmap() would always fail.<br>
>      ><br>
>      >         .<br>
>      >         Also I don't think that this project should be continued<br>
>     without<br>
>      >         a full DEBUGGING Setup.<br>
>      ><br>
>      ><br>
>      >     +1, without a proper debugging setup I found it hard to precisely<br>
>      >     pin point the problem when I initially took up this task.<br>
>      ><br>
>      ><br>
>      >         Best,<br>
>      >         Nils<br>
>      ><br>
>      >         On Tue, 23 Mar 2021 at 17:00, Christian MAUDERER<br>
>      >         <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
>     <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>><br>
>      >         <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
>     <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>>>> wrote:<br>
>      ><br>
>      >             Hello Gedare,<br>
>      ><br>
>      >             Am 23.03.21 um 16:48 schrieb Gedare Bloom:<br>
>      >              > CC: Nils, Utkarsh<br>
>      >              ><br>
>      >              > On Tue, Mar 23, 2021 at 9:17 AM Christian MAUDERER<br>
>      >              > <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
>     <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>><br>
>      >             <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
>     <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>>>> wrote:<br>
>      >              >><br>
>      >              >> Hello Ahamed,<br>
>      >              >><br>
>      >              >> Am 23.03.21 um 11:24 schrieb Ahamed Husni:<br>
>      >              >>> Hi everyone,<br>
>      >              >>><br>
>      >              >>> I'm really interested to work on the *Beagle BSP<br>
>      >             Projects* [#2891<br>
>      >              >>> <<a href="https://devel.rtems.org/ticket/2891" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/2891</a><br>
>     <<a href="https://devel.rtems.org/ticket/2891" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/2891</a>><br>
>      >             <<a href="https://devel.rtems.org/ticket/2891" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/2891</a><br>
>     <<a href="https://devel.rtems.org/ticket/2891" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/2891</a>>>>]. *<br>
>      >              >>> *<br>
>      >              >>> *Adding PRU Support* [#3730<br>
>      >             <<a href="https://devel.rtems.org/ticket/3730" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/3730</a><br>
>     <<a href="https://devel.rtems.org/ticket/3730" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/3730</a>><br>
>      >             <<a href="https://devel.rtems.org/ticket/3730" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/3730</a><br>
>     <<a href="https://devel.rtems.org/ticket/3730" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/3730</a>>>>]<br>
>      >              >>> project seems really interesting to me.<br>
>      >              >>> This project is partially done during GSoC 2019<br>
>      >              >>> <<a href="https://devel.rtems.org/wiki/GSoC/2019" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/GSoC/2019</a><br>
>     <<a href="https://devel.rtems.org/wiki/GSoC/2019" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/GSoC/2019</a>><br>
>      >             <<a href="https://devel.rtems.org/wiki/GSoC/2019" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/GSoC/2019</a><br>
>     <<a href="https://devel.rtems.org/wiki/GSoC/2019" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/GSoC/2019</a>>>>by Nils Hölscher .<br>
>      >              >>> Is this a good project for the GSoC?<br>
>      >              >>><br>
>      >              >>> Up to now I have,<br>
>      >              >>><br>
>      >              >>>   1. Completed the GSoC prerequisite task<br>
>      >              >>>   2. Got the required hardware and tested it.<br>
>      >             (Beagleboard Black, USB to<br>
>      >              >>>      TTL Converter)<br>
>      >              >>>   3. Installed RTEMS on the Beagleboard and tested.<br>
>      >             (Screenshot attached<br>
>      >              >>>      below)<br>
>      >              >>><br>
>      >              >>><br>
>      >              >>> I need guidance to define the scope of the project.<br>
>      >              >>> I'm currently thinking of ,<br>
>      >              >>><br>
>      >              >>>   1. First finish the remaining work from GSoC<br>
>     2019 on<br>
>      >             the PRU.<br>
>      >              >>>      (What is the status of current<br>
>     implementation of<br>
>      >             the PRU?)<br>
>      >              >><br>
>      >              >> I'm really not sure what the state of the PRU is. I<br>
>      >             didn't follow that<br>
>      >              >> project closely. Maybe one of the mentors of that<br>
>      >             project can say<br>
>      >              >> anything regarding that.<br>
>      >              >><br>
>      >              > Some more background:<br>
>      >              ><br>
>      > <a href="https://lists.rtems.org/pipermail/devel/2019-December/056478.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2019-December/056478.html</a><br>
>     <<a href="https://lists.rtems.org/pipermail/devel/2019-December/056478.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2019-December/056478.html</a>><br>
>      >           <br>
>       <<a href="https://lists.rtems.org/pipermail/devel/2019-December/056478.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2019-December/056478.html</a><br>
>     <<a href="https://lists.rtems.org/pipermail/devel/2019-December/056478.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2019-December/056478.html</a>>><br>
>      >              ><br>
>      > <a href="https://lists.rtems.org/pipermail/devel/2020-January/056958.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-January/056958.html</a><br>
>     <<a href="https://lists.rtems.org/pipermail/devel/2020-January/056958.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-January/056958.html</a>><br>
>      >           <br>
>       <<a href="https://lists.rtems.org/pipermail/devel/2020-January/056958.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-January/056958.html</a><br>
>     <<a href="https://lists.rtems.org/pipermail/devel/2020-January/056958.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-January/056958.html</a>>><br>
>      >              ><br>
>      >              > Maybe Utkarsh or Nils have more to say.<br>
>      >              ><br>
>      >              >>>   2. Implement additional peripheral support.<br>
>      >              >>>      What would be most useful?<br>
>      >              >>>      (USB OTG, CAN, ...).<br>
>      >              >><br>
>      >              >> I think CAN is a bit hard without some CAN analyzer<br>
>      >             hardware as a peer.<br>
>      >              >><br>
>      >              >> USB OTG would be a nice area. But that will be less<br>
>      >             writing a driver for<br>
>      >              >> Beagle but more finding out how that works with<br>
>     libbsd<br>
>      >             and finding a<br>
>      >              >> good way to configure it. I once put a few hours<br>
>     into it<br>
>      >             didn't take too<br>
>      >              >> much time till a PC detected an USB device (see<br>
>      >              >><br>
>      > <a href="https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce" rel="noreferrer" target="_blank">https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce</a><br>
>     <<a href="https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce" rel="noreferrer" target="_blank">https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce</a>><br>
>      >           <br>
>       <<a href="https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce" rel="noreferrer" target="_blank">https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce</a><br>
>     <<a href="https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce" rel="noreferrer" target="_blank">https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce</a>>>).<br>
>      >              >> Basically it's about importing the "usb_template"<br>
>     stuff<br>
>      >             and finding a<br>
>      >              >> way to configure it in libbsd.<br>
>      >              >><br>
>      >              >> I think that topic would have to be a bit of an open<br>
>      >             one: You might work<br>
>      >              >> only a day on it and have a working CDC Ethernet<br>
>      >             afterwards or you can<br>
>      >              >> need weeks for that. So you should add an open<br>
>     list of<br>
>      >             possible advanced<br>
>      >              >> targets. An OTG device can be:<br>
>      >              >><br>
>      >              >> - Ethernet<br>
>      >              >> - Serial port<br>
>      >              >> - Mass storage<br>
>      >              >> - Keyboard / Mouse<br>
>      >              >> - Modem<br>
>      >              >> - Audio<br>
>      >              >> - ...<br>
>      >              >><br>
>      >              >> The simplest one will most likely be Ethernet<br>
>     followed<br>
>      >             by serial port. I<br>
>      >              >> would add some of the others (like mass storage)<br>
>     as an<br>
>      >             extended targets.<br>
>      >              >><br>
>      >              > Yes, this seems like an area that can be chipped<br>
>     away at,<br>
>      >             with a<br>
>      >              > strong plan of activities. My concern would be<br>
>     whether it<br>
>      >             is about<br>
>      >              > writing code or not?<br>
>      >              ><br>
>      ><br>
>      >             It won't produce a lot of code. But it will produce<br>
>     relevant<br>
>      >             one:<br>
>      ><br>
>      >             1. Interface for configuration (if necessary)<br>
>      ><br>
>      >             2. Example application<br>
>      ><br>
>      >             3. Documentation<br>
>      ><br>
>      >             For Ethernet and serial port that's most likely it.<br>
>     For Mass<br>
>      >             storage<br>
>      >             there might be some more code. Without a too detailed<br>
>     look:<br>
>      >             I would<br>
>      >             expect that the mass storage either implements some<br>
>     access<br>
>      >             to a raw<br>
>      >             block device - in which case it would be necessary to add<br>
>      >             the access to<br>
>      >             block devices. Or it implements something like the<br>
>     PTP stuff<br>
>      >             used on<br>
>      >             smartphones in which case there will be most likely some<br>
>      >             code that<br>
>      >             accesses the file system using POSIX functions instead of<br>
>      >             FreeBSD kernel<br>
>      >             functions.<br>
>      ><br>
>      >             Best regards<br>
>      ><br>
>      >             Christian<br>
>      ><br>
>      >              >> Best regards<br>
>      >              >><br>
>      >              >> Christian<br>
>      >              >><br>
>      >              >>><br>
>      >              >>>      The builtin USB is NOT functional other<br>
>     than for<br>
>      >             power under RTEMS.<br>
>      >              >>>      (USB OTG would have to be implemented in<br>
>     RTEMS to<br>
>      >             get rid of USB to<br>
>      >              >>>      TTL Converter.)<br>
>      >              >>>      - Ben Gras<br>
>      >              >>><br>
>      >           <br>
>       <<a href="http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html" rel="noreferrer" target="_blank">http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html</a> <<a href="http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html" rel="noreferrer" target="_blank">http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html</a>><br>
>      >           <br>
>       <<a href="http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html" rel="noreferrer" target="_blank">http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html</a> <<a href="http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html" rel="noreferrer" target="_blank">http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html</a>>>><br>
>      >              >>>      (Blog post)<br>
>      >              >>><br>
>      >              >>><br>
>      >              >>> Thanks,<br>
>      >              >>> Husni Faiz.<br>
>      >              >>><br>
>      >              >>><br>
>      >              >>> BBB_Serial_Out.png<br>
>      >              >>><br>
>      >              >>><br>
>      >              >>> _______________________________________________<br>
>      >              >>> devel mailing list<br>
>      >              >>> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>><br>
>     <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>>><br>
>      >              >>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>     <<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a>><br>
>      >             <<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>     <<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a>>><br>
>      >              >>><br>
>      >              >><br>
>      >              >> --<br>
>      >              >> --------------------------------------------<br>
>      >              >> embedded brains GmbH<br>
>      >              >> Herr Christian MAUDERER<br>
>      >              >> Dornierstr. 4<br>
>      >              >> 82178 Puchheim<br>
>      >              >> Germany<br>
>      >              >> email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
>     <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>><br>
>      >             <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
>     <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>>><br>
>      >              >> phone: +49-89-18 94 741 - 18<br>
>      >              >> fax:   +49-89-18 94 741 - 08<br>
>      >              >><br>
>      >              >> Registergericht: Amtsgericht München<br>
>      >              >> Registernummer: HRB 157899<br>
>      >              >> Vertretungsberechtigte Geschäftsführer: Peter<br>
>     Rasmussen,<br>
>      >             Thomas Dörfler<br>
>      >              >> Unsere Datenschutzerklärung finden Sie hier:<br>
>      >              >> <a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
>     <<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a>><br>
>      >             <<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
>     <<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a>>><br>
>      >              >> _______________________________________________<br>
>      >              >> devel mailing list<br>
>      >              >> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>><br>
>     <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>>><br>
>      >              >> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>     <<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a>><br>
>      >             <<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>     <<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a>>><br>
>      ><br>
>      >             --<br>
>      >             --------------------------------------------<br>
>      >             embedded brains GmbH<br>
>      >             Herr Christian MAUDERER<br>
>      >             Dornierstr. 4<br>
>      >             82178 Puchheim<br>
>      >             Germany<br>
>      >             email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
>     <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>><br>
>      >             <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
>     <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>>><br>
>      >             phone: +49-89-18 94 741 - 18<br>
>      >             fax:   +49-89-18 94 741 - 08<br>
>      ><br>
>      >             Registergericht: Amtsgericht München<br>
>      >             Registernummer: HRB 157899<br>
>      >             Vertretungsberechtigte Geschäftsführer: Peter Rasmussen,<br>
>      >             Thomas Dörfler<br>
>      >             Unsere Datenschutzerklärung finden Sie hier:<br>
>      > <a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
>     <<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a>><br>
>      >             <<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
>     <<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a>>><br>
>      ><br>
> <br>
>     -- <br>
>     --------------------------------------------<br>
>     embedded brains GmbH<br>
>     Herr Christian MAUDERER<br>
>     Dornierstr. 4<br>
>     82178 Puchheim<br>
>     Germany<br>
>     email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
>     <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>><br>
>     phone: +49-89-18 94 741 - 18<br>
>     fax:   +49-89-18 94 741 - 08<br>
> <br>
>     Registergericht: Amtsgericht München<br>
>     Registernummer: HRB 157899<br>
>     Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
>     Unsere Datenschutzerklärung finden Sie hier:<br>
>     <a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
>     <<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a>><br>
> <br>
> <br>
> <br>
> -- <br>
> Husni<br>
> <br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <br>
</blockquote></div>