<div dir="ltr"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im">>  Â  Â Yes, this seems like an area that can be chipped away at, with a</span><br><span class="gmail-im">
>  Â  Â strong plan of activities. My concern would be whether it is about</span><br><span class="gmail-im">
>  Â  Â writing code or not?</span><br><span class="gmail-im">
> </span><br><span class="gmail-im">
> </span><br><span class="gmail-im">
> After completing the above milestones, if we have more time I can start </span><br><span class="gmail-im">
> to work on</span><br><span class="gmail-im">
> the Mass storage support.</span><br><span class="gmail-im">
></span> <br></blockquote><span class="gmail-im">
<br></span>
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 estimate <br>
in my point of view. Do you have an idea how we could handle that?<span class="gmail-im"><br></span></div></blockquote><div><br></div><div>So do I have to include mass storage support into the project schedule or</div><div>should I prepare the schedule for Ethernet, Serial  <span class="gmail-im">and add the list of <br></span></div><div><span class="gmail-im">possible advances</span> and say that I'll work on them if there is enough time?<br></div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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. 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 running.<br></blockquote><div><br></div><div>I don't have a JTAG debugger now. I'll get that set up asap.</div><div><br></div><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im">>     USB OTG would be a nice area. But that will be less writing a driver</span><br><span class="gmail-im">
>  Â  Â for</span><br><span class="gmail-im">
>  Â  Â Beagle but more finding out how that works with libbsd and finding a</span><br><span class="gmail-im">
>  Â  Â good way to configure it. I once put a few hours into it didn't take</span><br><span class="gmail-im">
>  Â  Â too</span><br><span class="gmail-im">
>  Â  Â much time till a PC detected an USB device (see</span><br><span class="gmail-im">
>  Â  Â <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></span><br><span class="gmail-im"></span>
>  Â  Â <<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>>).<span class="gmail-im"></span><br><span class="gmail-im">
>  Â  Â Basically it's about importing the "usb_template" stuff and finding a</span><br><span class="gmail-im">
>  Â  Â way to configure it in libbsd.</span></blockquote><div><br></div><div>I'm trying to build and test this branch. I had trouble with building the libbsd.<br></div><div>So I started to build the tools and kernel from scratch with the RSB master, using <br></div><div>beaglebone black bset. It gives me the following error.<br>Error log: <a href="https://pastebin.com/NYZRej1B">https://pastebin.com/NYZRej1B</a><br><br>Build command<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">../source-builder/sb-set-builder --log=beagle.txt --prefix=$BASE/rtems/6 bsps/beagleboneblack.bset</blockquote></div><div> </div>What would be the steps to configure the USB OTG driver from libbsd to BBB.<br></div><div>I would like to try it out. Please guide me on this.</div><div><br></div><div>Best regards,<br></div></div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 26, 2021 at 8:17 PM Christian MAUDERER <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.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">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 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>
>  Â  Â Basically it's about importing the "usb_template" stuff 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 one: You might<br>
>  Â  Â work<br>
>  Â  Â only a day on it and have a working CDC Ethernet afterwards 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 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. 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 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 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 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 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>
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 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 unable<br>
>  Â  Â to communicate with it in a meaningful way.<br>
>  Â  Â Also I don't think that this project should be continued 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 <<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 <<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>>> 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 that<br>
>  Â  Â mmap() would always fail.<br>
> <br>
>  Â  Â  Â  Â .<br>
>  Â  Â  Â  Â Also I don't think that this project should be continued 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>>> 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>>> 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>
>  Â  Â  Â  Â  Â  Â  >>> *<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>
>  Â  Â  Â  Â  Â  Â  >>> 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>>>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 2019 on<br>
>  Â  Â  Â  Â  Â  Â the PRU.<br>
>  Â  Â  Â  Â  Â  Â  >>>  Â  Â  (What is the status of current 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/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 libbsd<br>
>  Â  Â  Â  Â  Â  Â and finding a<br>
>  Â  Â  Â  Â  Â  Â  >> good way to configure it. I once put a few hours 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>
>  Â  Â  Â  Â  Â  Â  >> Basically it's about importing the "usb_template" 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 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 followed<br>
>  Â  Â  Â  Â  Â  Â by serial port. I<br>
>  Â  Â  Â  Â  Â  Â  >> would add some of the others (like mass storage) as an<br>
>  Â  Â  Â  Â  Â  Â extended targets.<br>
>  Â  Â  Â  Â  Â  Â  >><br>
>  Â  Â  Â  Â  Â  Â  > Yes, this seems like an area that can be chipped away at,<br>
>  Â  Â  Â  Â  Â  Â with a<br>
>  Â  Â  Â  Â  Â  Â  > strong plan of activities. My concern would be 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 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. For Mass<br>
>  Â  Â  Â  Â  Â  Â storage<br>
>  Â  Â  Â  Â  Â  Â there might be some more code. Without a too detailed look:<br>
>  Â  Â  Â  Â  Â  Â I would<br>
>  Â  Â  Â  Â  Â  Â expect that the mass storage either implements some 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 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 than for<br>
>  Â  Â  Â  Â  Â  Â power under RTEMS.<br>
>  Â  Â  Â  Â  Â  Â  >>>  Â  Â  (USB OTG would have to be implemented in RTEMS to<br>
>  Â  Â  Â  Â  Â  Â get rid of USB to<br>
>  Â  Â  Â  Â  Â  Â  >>>  Â  Â  TTL Converter.)<br>
>  Â  Â  Â  Â  Â  Â  >>>  Â  Â  - Ben Gras<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><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>>><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>
>  Â  Â  Â  Â  Â  Â  >>> <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>
>  Â  Â  Â  Â  Â  Â  >> 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>
>  Â  Â  Â  Â  Â  Â  >> _______________________________________________<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>
>  Â  Â  Â  Â  Â  Â  >> <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>
>  Â  Â  Â  Â  Â  Â 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>
> <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>
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>
</blockquote></div>
<br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Husni<br></div></div>