GSoC Project - Beagle BSP Projects
Ahamed Husni
ahamedhusni73 at gmail.com
Fri May 7 00:40:04 UTC 2021
Hi,
Sorry for not providing detailed explanations and for the late response.
On Sun, May 2, 2021 at 5:31 PM Christian Mauderer <oss at 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 <oss at c-mauderer.de
> > <mailto:oss at 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.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at embedded-brains.de>
> > > <mailto:christian.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at 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.rai60 at gmail.com <mailto:utkarsh.rai60 at gmail.com>
> > <mailto:utkarsh.rai60 at gmail.com <mailto:utkarsh.rai60 at gmail.com>>
> > > > <mailto:utkarsh.rai60 at gmail.com
> > <mailto:utkarsh.rai60 at gmail.com>
> > > <mailto:utkarsh.rai60 at gmail.com
> > <mailto:utkarsh.rai60 at gmail.com>>>> wrote:
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Mar 23, 2021 at 9:36 PM Nils Hölscher
> > > <nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>
> > <mailto:nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>>
> > > > <mailto:nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>
> > <mailto:nilhoel1 at gmail.com <mailto:nilhoel1 at 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.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at embedded-brains.de>
> > > <mailto:christian.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at embedded-brains.de>>
> > > > <mailto:christian.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at embedded-brains.de>
> > > <mailto:christian.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at 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.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at embedded-brains.de>
> > > <mailto:christian.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at embedded-brains.de>>
> > > > <mailto:christian.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at embedded-brains.de>
> > > <mailto:christian.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at 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 at rtems.org <mailto:devel at rtems.org>
> > <mailto:devel at rtems.org <mailto:devel at rtems.org>>
> > > <mailto:devel at rtems.org <mailto:devel at rtems.org>
> > <mailto:devel at rtems.org <mailto:devel at 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.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at embedded-brains.de>
> > > <mailto:christian.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at embedded-brains.de>>
> > > > <mailto:christian.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at embedded-brains.de>
> > > <mailto:christian.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at 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 at rtems.org <mailto:devel at rtems.org>
> > <mailto:devel at rtems.org <mailto:devel at rtems.org>>
> > > <mailto:devel at rtems.org <mailto:devel at rtems.org>
> > <mailto:devel at rtems.org <mailto:devel at 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.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at embedded-brains.de>
> > > <mailto:christian.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at embedded-brains.de>>
> > > > <mailto:christian.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at embedded-brains.de>
> > > <mailto:christian.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at 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.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at embedded-brains.de>
> > > <mailto:christian.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at 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 at rtems.org <mailto:devel at rtems.org>
> > > http://lists.rtems.org/mailman/listinfo/devel
> > <http://lists.rtems.org/mailman/listinfo/devel>
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210507/42a39820/attachment-0001.html>
More information about the devel
mailing list