Hi, Sorry for not providing detailed explanations and for the late response.
On Sun, May 2, 2021 at 5:31 PM Christian Mauderer <o...@c-mauderer.de> wrote: > Hello Husni, > > On 01/05/2021 23:38, Ahamed Husni wrote: > > Hi all, > > > > My project proposal > > > https://docs.google.com/document/d/1CN3ri7g6NJeFPb5h8y4smr1aziGWyXbiiXUsFMhdUu4/edit?usp=sharing > > < > https://docs.google.com/document/d/1CN3ri7g6NJeFPb5h8y4smr1aziGWyXbiiXUsFMhdUu4/edit?usp=sharing > > > > > > I tried to set up the JTAG Environment for the Beaglebone Black. > > But I couldn't find the hardware anywhere in my country (Sri Lanka). > > > > I tried to, > > > > 1. Find TI XDS Debuggers > > 2. Find a TI Launchpad so we can isolate and use the debugger in it. > > I assume you didn't find these? Yes, that was the case until yesterday. Luckily I was able to find a TI Launchpad CC1310 board. Due to the Covid situation in the country, I'll only be able to get the hardware on Monday. So until then I won't be able to try anything related to JTAG. Also I will need an ARM10-cTI20 JTAG adapter to use the XDS110 debugger in the launchpad. I'll find it asap. > > 3. Use RPi as a debugger using OpenOCD > > I would have expect that one to work (like nearly any OpenOCD debugger). > What was the problem? Did OpenOCD detect the processor? What pins did > you connect? Please provide some more details so we might can help with > tips. > No. I didn't try it myself. I found a discussion in TI. It looks like someone has tried it and wasn't successful. I didn't understand most of the technical stuff in the discussion. It seems like he was able to program with JTAG but not debug. https://e2e.ti.com/support/processors/f/processors-forum/777331/am3358-how-to-evaluate-if-a-jtag-chain-works-correctly By the way: If you get it running it might would be a nice addition to > the user manual: > > > https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#debugging-beagle-bone-black-using-a-jtag-debugger-and-gdb > > That's currently mostly about the gdb part. You maybe could add two or > three sentences and program calls how to start OpenOCD on a beagle and > what pins can be used for it. > > > > > I looked for the debuggers in major electronic shops, embedded systems > > related companies, > > university labs and etc. But couldn't find them. > > Also these debuggers are expensive. When ordering online the shipping > > charges are also high. > > I know from past GSoC that it can be difficult to get certain stuff in > some countries. That's OK and I'm sure we find some solution. > > > So I can't guarantee that I can set up JTAG. > > > > Can we use RTEMS Libdebugger until we figure out the JTAG? > > I did too few stuff with libdebugger. So I don't know it really well. I > _think_ that it needs a working network stack which would mean that you > can only use it _after_ libbsd is initialized. > > Anyone: Please correct me if I'm wrong. If it would for example work > with a serial interface, it should be OK. > > > Can we make a fallback plan for this project? If yes, what sorts of > > changes should be made? > > I think the next best thing if you don't have a hardware debugger would > be the RTEMS event recording. You have to instrument code and the > processor has to be able to print an exception so you can get the data. > You can't check anything on a instruction level but it's a great tool if > you have to analyze the execution order of some problem cases. Most > likely that will work for a lot of problems in your project too. So I > would say that should be a fallback. Maybe you want to have a look at that: > > https://docs.rtems.org/branches/master/user/tracing/eventrecording.html > > Basically it's adding a few CONFIGURE_RECORD_... defines to your > application, receive events with rtems-record-lttng via network or from > a serial dump and then using Eclipse Trace Compass to analyze the trace. > Please speak up if you need help setting that up. > > For the last couple of days I've been learning about the rtems-libbsd. I have built and installed the rtems-libbsd. I ran the Telnet testsuite on the hardware. Serial output is here <https://pastebin.com/c7C2R7Fj>. Next I'll try out the libdebugger and event recording till I get the JTAG hardwares. Best regards, Husni. Best regards > > Christian > > > > > Best regards, > > Husni. > > > > On Fri, Apr 2, 2021 at 6:16 PM Christian Mauderer <o...@c-mauderer.de > > <mailto: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>> > > > > > > > > > <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> <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 > > <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 > > <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> > > > <mailto: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>> > > > > > > > > > <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>> > > > > <mailto: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>> > > > > <mailto: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>> > > > > <mailto: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>> > > > > <mailto: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>> > > > > <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>> > > > > <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>> > > > > <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/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>> > > > > > > > > > <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>> > > > > > > > > > <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 > >> > > > > > > > > > < > 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>> > > > <mailto: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>> > > > > <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>> > > > > <mailto: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/>> > > > > > > <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>> > > > <mailto: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>> > > > > <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>> > > > > <mailto: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/>> > > > > > > <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> > > > <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/>> > > > > > > > > > > > > -- > > > Husni > > > > > > _______________________________________________ > > > devel mailing list > > > devel@rtems.org <mailto:devel@rtems.org> > > > http://lists.rtems.org/mailman/listinfo/devel > > <http://lists.rtems.org/mailman/listinfo/devel> > > > > > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel