Re: GSoC Project - Beagle BSP Projects

Christian Mauderer Sun, 02 May 2021 05:02:05 -0700

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?

 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 didyou connect? Please provide some more details so we might can help withtips.

By the way: If you get it running it might would be a nice addition tothe 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 orthree sentences and program calls how to start OpenOCD on a beagle andwhat pins can be used for it.

I looked for the debuggers in major electronic shops, embedded systemsrelated companies,
university labs and etc. But couldn't find them.
Also these debuggers are expensive. When ordering online the shippingcharges are also high.

I know from past GSoC that it can be difficult to get certain stuff insome 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 youcan only use it _after_ libbsd is initialized.

Anyone: Please correct me if I'm wrong. If it would for example workwith a serial interface, it should be OK.

Can we make a fallback plan for this project? If yes, what sorts ofchanges should be made?

I think the next best thing if you don't have a hardware debugger wouldbe the RTEMS event recording. You have to instrument code and theprocessor 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 ifyou have to analyze the execution order of some problem cases. Mostlikely that will work for a lot of problems in your project too. So Iwould 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 yourapplication, receive events with rtems-record-lttng via network or froma serial dump and then using Eclipse Trace Compass to analyze the trace.Please speak up if you need help setting that up.


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>>

     >      >

     >      >              >>>      (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

Re: GSoC Project - Beagle BSP Projects

Reply via email to