What do you want to study in GSOC 2020?
Christian Mauderer
list at c-mauderer.de
Fri Jan 3 19:59:30 UTC 2020
On 03/01/2020 18:37, Niteesh wrote:
> On Fri, Jan 3, 2020 at 7:30 PM Christian Mauderer <list at c-mauderer.de
> <mailto:list at c-mauderer.de>> wrote:
>
> On 03/01/2020 13:49, Niteesh wrote:
> > I have gone through previous year works and selected a few topics
> which
> > I found
> > interesting.
> > 1. Basic Support for Trace Compass #3696
> > <https://devel.rtems.org/ticket/3696>.
>
> A basic support has been added last year and Sebastian extended that
> quite a bit because we had a customer who needed it. I'm not sure what
> the current state is and whether there are tasks left that could be done
> in a GSoC project.
>
> > 2. RTEMS testing tool project #2927
> <https://devel.rtems.org/ticket/2927>.
>
> No idea what the status is. Chris?
>
> > 3. Beagle BSP: Add a flattened device tree based initialization #3784
> > <https://devel.rtems.org/ticket/3784>.
>
> That one is open. It would include adding some infrastructure for fdt
> based drivers. In theory you could do the same project for raspberry or
> any other board.
>
> Please note Gedares comment from the previous mail:
>
> > Infrastructure projects are nice (FDT, dynamic linking, debugger,
> > tracer) but need to be clearly defined ahead of time and discussed
> > thoroughly with the community, or you risk ending up in the "long
> > tedious discussions" when you should be coding.
>
>
> > 4. BSPs for Simulators #2903 <https://devel.rtems.org/ticket/2903>.
>
> That's always open.
>
> Some simulators are easy because the board is already supported and you
> only have to find out how to start it. For these a tester integration is
> a good target. But most likely that's only small stuff and should be
> only one part of a project.
>
> Other simulators are not supported yet. In that case you have to write
> some drivers which can be a good project size.
>
> > 5. Improve the Raspberry Pi BSP #2899
> <https://devel.rtems.org/ticket/2899>.
>
> You already noted: The raspberry BSP isn't in the best shape. So it's
> quite open for improvement.
>
> I think that there is still some work getting it to run again. We don't
> have something with "*bcm*" in libbsd yet so most likely USB and
> Ethernet are not working yet. Could be still still be a nice task.
>
>
> Why don't we use the driver's from other sources as a reference and
> create our
> own, for USB https://github.com/Chadderz121/csud this could be used as a
> reference, U-boot, and Linux are good sources too. But is it worth the
> effort for a
> BSP like raspberry pi? There is also a c++ bare metal environment called
> circle
> https://github.com/rsta2/circle which supports
> USB(https://github.com/rsta2/uspi)
> and ethernet.
The reason for using libbsd is that its already there and therefore its
easy to add for all chips that are supported (and raspberry is supported
in FreeBSD).
U-Boot and Linux can't be used most of the time due to license issues.
Both have a GPL license which isn't usable in a lot of RTEMS
applications (industrial, automotive, ...). There shouldn't be any GPL
code in the core repository and we tend to avoid libraries if there are
alternatives.
>
> Christian, can you check out this https://github.com/0xabu/qemu/wiki it
> partially supports
> USB, can you give it a try?
RTEMS with libbsd doesn't yet have a USB support committed for the
raspberry. Do you mean try it with Linux or Windows? Did you already
test something? What do you want to find out?
>
>
> With the difficulties getting it to run on RPi3 or RPi4 that might could
> be also a project. It seems that they are aarch64. Also I was quite
> surprised about it I didn't find a aarch64 BSP. So that would be a
> new port.
>
>
> Rpi3 looks for kernel7.img if it finds one, it boots into 32bit mode, so
> if the, offset is the only difference
> between rpi2 and rpi3 it should boot without any issues I'll try adding
> the AUX uart driver
> and see if it boots on Rpi3.
Don't forget to add a "kernel_address=0x00200000" line if you use the
linker file like it is currently there in RTEMS.
>
> I would also like to discuss about the FDT infrastructure for RTEMS, I
> would like to know what are
> the requirements, what could be expected in a short span of 3months,
> what could be used as a reference
> and so on.
We use a lot of FreeBSD stuff (because it has a matching license and is
quite well designed most of the time). So I would suggest to take a look
how the FDT stuff works in FreeBSD and whether we can adopt or port the
interface - maybe slightly adapted to RTEMS needs like having an early
initialization for the console driver. Porting or implementing that and
adapting a few drivers as proof of concept should be possible in the
given time if you discuss the basic direction before the coding starts.
Please note (for any project you pick): If there is some unexpected work
along the way, the initial plan can be adapted. So don't be afraid that
you might not manage to get everything done. In such a case you just
have to talk to your mentor (which you should do anyway on a regular basis).
>
> Note that an aarch64 port would most likely be observed with argus eyes
> because it has the potential to be a very important port. But don't let
> that keep you bag suggesting it.
>
> >
> > I would like to know what are the future plans for these topics.
> > What is the current status of USB and ethernet in raspberrypi?
> > Does the beagle BSP require hardware or is it possible to emulate it?
>
> I never used an emulator for Beagle. It seems that qemu supported it
> some when:
> https://www.cnx-software.com/2011/09/26/beagleboard-emulator-in-ubuntu-with-qemu/
>
> But I didn't find it in current qemu. So most likely it would need
> hardware.
>
> > Last year Vijay Kumar Banerjee worked on analysis and generation
> of gcov
> > reports.
> >
> > On Thu, Jan 2, 2020 at 10:07 PM Gedare Bloom <gedare at rtems.org
> <mailto:gedare at rtems.org>
> > <mailto:gedare at rtems.org <mailto:gedare at rtems.org>>> wrote:
> >
> > On Mon, Dec 30, 2019 at 2:47 PM Christian Mauderer
> > <list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>> wrote:
> > >
> > > On 30/12/2019 15:45, Niteesh wrote:
> > > > On Mon, Dec 30, 2019 at 7:14 PM Christian Mauderer
> > <list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
> > > > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>> wrote:
> > > >
> > > > On 30/12/2019 07:25, Niteesh wrote:
> > > > >
> > > > >
> > > > > On Mon, Dec 30, 2019 at 4:44 AM Peter Dufault
> > <dufault at hda.com <mailto:dufault at hda.com>
> <mailto:dufault at hda.com <mailto:dufault at hda.com>>
> > > > <mailto:dufault at hda.com <mailto:dufault at hda.com>
> <mailto:dufault at hda.com <mailto:dufault at hda.com>>>
> > > > > <mailto:dufault at hda.com <mailto:dufault at hda.com>
> <mailto:dufault at hda.com <mailto:dufault at hda.com>>
> > <mailto:dufault at hda.com <mailto:dufault at hda.com>
> <mailto:dufault at hda.com <mailto:dufault at hda.com>>>>> wrote:
> > > > >
> > > > >
> > > > > Niteesh, what do you want to study? Go over
> what most
> > > > interests you
> > > > > most about working in a real-time environment like
> > RTEMS, and not
> > > > > about working on the RPI, and look at the
> earlier GSOC
> > projects.
> > > > > Propose an ideal project for yourself and get some
> > feedback.
> > > >
> > > > Peter: Thanks for starting that discussion. I started to
> > focus too much
> > > > on the running topics about small stuff that can be
> done as a
> > > > preparation.
> > > >
> > > > >
> > > > > I love learning about how the software and hardware
> > interact, I have
> > > > > been programming from 9th grade and have a wide
> variety of
> > > > > interests(networking, app development). But recently I
> > took a course
> > > > > called nandtotetris were we build an 8bit computer from
> > scratch, we
> > > > > start with NAND gates and finally finish with a
> Tetris game.
> > > >
> > > > That sounds like a really nice course. Most likely is
> ended
> > in a bigger
> > > > pile of circuit boards to have a running processor ;-)
> > > >
> > > > It is a free course on
> > > > coursera
> > https://www.coursera.org/learn/build-a-computer/home/welcome
> > > > do check it out. It's completely simulated in software. But
> > planning to
> > > > build it on PCB.
> > > >
> > > >
> > > > > Low-level
> > > > > software, systems programming, and operating systems are
> > always quite
> > > > > fascinating for me. While learning about operating
> > systems, I came
> > > > > across the concepts of real-time systems. Back then
> > arduino was
> > > > the only
> > > > > hardware I was having while searching for an RTOS to
> play
> > with, I came
> > > > > across RTEMS. RTOS was harder for me to grasp but
> were always
> > > > > interesting, being a critical part of a system, I always
> > wanted to
> > > > learn
> > > > > how they worked from inside. That's what bought me to
> > contributing
> > > > to RTOS.
> > > > > I wanted to contribute to core of RTEMS, but it was
> a bit
> > complex
> > > > for me
> > > > > to understand, so I started with driver development
> for RTEMS.
> > > >
> > > > That's where I started too. But don't hesitate to pick a
> > more complex
> > > > topic if you are interested in it. From what I've seen you
> > can read and
> > > > understand existing code quite fast compared to some other
> > GSoC students
> > > > we had. So I would say that you have a good chance to
> manage
> > complex
> > > > topics too.
> > > >
> > > > Thank you, it's quite good to hear.
> > > >
> > > > > After going through some of the previous GSOC
> projects, BSP
> > > > development
> > > > > and real-time tracing are what I find interesting.
> While also
> > > > converting
> > > > > the console driver of rpi to FDT based one, *Christian
> > Mauderer
> > > > > *explained how
> > > > > FDT worked in FreeBSD and Linux, and RTEMS lacked that
> > > > infrastructure, I
> > > > > have no idea of how hard it would it, and if I am even
> > capable of
> > > > > developing it. But one proposal would be to build
> the FDT
> > > > infrastructure
> > > > > similar to FreeBSD or Linux and have the driver's probe
> > and attach to
> > > > > the hardware.
> > > >
> > > > We start to have more and more FDT based BSPs. So it would
> > be great if
> > > > our infrastructure would improve. But like I said: Don't
> > hesitate to
> > > > pick any other topic. Device drivers (and similar) are low
> > hanging fruit
> > > > where it is easy to get success and it isn't very
> likely to
> > start long
> > > > tedious discussions because you only touch one BSP.
> > Therefore I tend to
> > > > suggest them for GSoC. But GSoC isn't limited to that.
> > > >
> > > > So if you would like to work at any other topic like (for
> > example)
> > > > porting a new architecture, hacking on some scheduler, do
> > something with
> > > > the dynamic linking support, add stuff to the libdebugger,
> > or basically
> > > > anything else: Just ask whether someone knows a topic in
> > that area or is
> > > > interested in mentoring one you suggest. Most likely the
> > mailing list
> > > > will become quite a bit more active again in about a week.
> > > >
> > I'll be lurking.
> >
> > Infrastructure projects are nice (FDT, dynamic linking, debugger,
> > tracer) but need to be clearly defined ahead of time and discussed
> > thoroughly with the community, or you risk ending up in the "long
> > tedious discussions" when you should be coding.
> >
> > BSP Projects are only good if they are useful. RPI3 might be
> useful,
> > although there haven't been a lot of folks clamoring for it.
> >
> > > > Once I finish with the raspberry pi, I will try to port RTEMS
> > for esp32.
> > > > I have that board,
> > > > It has quite a lot of features and really good
> documentation. It is
> > > > based on xtensa CPU.
> > > > https://devel.rtems.org/wiki/TBR/UserManual/SupportedCPUs
> and is
> > under
> > > > RTEMS potential port.
> > > >
> > >
> > > Interesting idea. You should post that as a project idea for
> your GSoC
> > > project. There are quite some points for new cores that can
> make a
> > port
> > > very simple or hard as hell. I don't have the experience to
> give a
> > good
> > > estimate for that core. But don't worry. I'm quite sure that
> this
> > can be
> > > an interesting project.
> > >
> > > Just some random thoughts:
> > >
> > > - It seems that the Xtensa is supported in the official GCC
> since
> > quite
> > > some time up to the most recent releases. That's a really good
> > starting
> > > point.
> > >
> > > - The core is a commercial IP core. It might can get hard to
> get a
> > > detailed core documentation. Let's hope that there is enough
> community
> > > documentation for it.
> > >
> > > - I didn't really find the core in any other (buyable) chip
> but the
> > > ESP32. Do you know whether it is used somewhere else?
> > >
> > > - The ESP32 doesn't have too much RAM. If I've seen it right
> it's
> > 520kB
> > > on-chip. We have smaller targets than that but it's not really
> > much. The
> > > libbsd network stack will most likely never run on it. But
> lwIP should
> > > work. But I think network stack is something that won't be a
> topic
> > for a
> > > first port anyway ;-)
> > >
> > > - The Technical Reference Manual looks reasonable detailed:
> > >
> >
> https://docs.espressif.com/projects/esp-idf/en/latest/hw-reference/index.html
> > >
> > > - For the low level port you definitively need a hardware
> debugger
> > or a
> > > good simulator. It seems that JTAG access is possible using
> OpenOCD.
> > > There is even an official guide from the manufacturer:
> > >
> >
> https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/jtag-debugging/
> > >
> >
> > A new architecture port is a worthwhile GSoC Project. There
> would be a
> > lot of learning and code generated. However as above there is a
> > question about utility: Will there be more than 1 xtensa user?
> > Historically, DPSs seem to have low demand for an RTOS like
> RTEMS. It
> > is still a good GSoC project though. One of the barriers to a new
> > architecture however will be testability: is there a simulator
> that
> > can be used for development/testing?
> >
> > For difficulty, the thing to investigate is how complex is the
> > register context, interrupt handling mechanisms, memory
> management,
> > and on-chip devices (timers, etc.). Also whether or not there is a
> > 2/3-BSD compliant port elsewhere for reusable code. The base
> xtensa
> > looks straightforward. The ESP32 is an interesting board.
> >
> > > >
> > > > >
> > > > > > On Dec 28, 2019, at 05:12 , Christian Mauderer
> > > > <list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>
> > > > > <mailto:list at c-mauderer.de
> <mailto:list at c-mauderer.de> <mailto:list at c-mauderer.de
> <mailto:list at c-mauderer.de>>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>>> wrote:
> > > > > >
> > > > > > On 28/12/2019 07:12, Niteesh wrote:
> > > > > >>
> > > > > >>
> > > > > >> On Sat, 28 Dec, 2019, 3:51 AM Christian Mauderer,
> > > > > <list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>
> > > > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>>
> > > > > >> <mailto:list at c-mauderer.de
> <mailto:list at c-mauderer.de>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>
> > > > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>>>> wrote:
> > > > > >>
> > > > > >> On 27/12/2019 19:06, Niteesh wrote:
> > > > > >>> Is there something else that I could work
> on? I am
> > > > interested in
> > > > > >> taking
> > > > > >>> part
> > > > > >>> GSOC of 2020. And I want to learn as much as
> possible.
> > > > > >>
> > > > > >> Do you search tasks specific to raspberry
> or general
> > > > ones? Do
> > > > > you search
> > > > > >> something for GSoC or just to warm up?
> > > > > >>
> > > > > >> Anything is fine as long as I am learning
> > something. Since rpi3
> > > > > is the
> > > > > >> only hardware I have, I am interested in tasks
> > specific to
> > > > raspi and
> > > > > >> general ones which do not require any hardware.
> > > > > >
> > > > > > For raspberry I think you could continue to get it
> > running
> > > > on RPi3. My
> > > > > > suggestion would be to replace the table based
> > initialization
> > > > > (which is
> > > > > > handled by console-termios-init.c) with one
> based on
> > the fdt
> > > > that is
> > > > > > similar to the one in the imx BSP. That will allow
> > to use
> > > > the same
> > > > > > binary on RPi2 and RPi3. But please do that in an
> > extra patch
> > > > > after the
> > > > > > one that you currently have sent to the
> mailing list.
> > > > > >
> > > > > >
> > > > > > Some other raspberry specific topics could be the
> > following.
> > > > Note that
> > > > > > this are only suggestions. I don't want to
> force you
> > to do
> > > > any of them
> > > > > > if you don't like them:
> > > > > >
> > > > > > - Documentation how you run an application in
> QEMU /
> > on real
> > > > hardware
> > > > > > for the user manual:
> > > > > >
> > > > >
> > > >
> >
> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#raspberrypi
> > > > > > (I hope I didn't miss a patch that you already
> sent
> > ;-) )
> > > > > >
> > > > > > - A configuration for RTEMS tester that uses
> the QEMU or
> > > > real hardware
> > > > > > (I think the pi3 allows network boot?). This
> allows
> > regular
> > > > test runs
> > > > > > for this BSP:
> > > > > >
> > > >
> >
> https://docs.rtems.org/branches/master/user/testing/index.html and
> > > > > >
> > https://docs.rtems.org/branches/master/user/tools/tester.html
> > > > > >
> > > > > > - Chris created a boot image generator last
> year. It
> > would
> > > > be great if
> > > > > > you could add a configuration to create
> raspberry SD
> > images
> > > > to it:
> > > > > >
> > > >
> > https://docs.rtems.org/branches/master/user/tools/boot-image.html
> > > > > >
> > > > > > - You can pick basically any component that isn't
> > already
> > > > there and
> > > > > > integrate it. If you want to work with libbsd:
> > Testing or
> > > > porting
> > > > > > Ethernet support could be something.
> > > > > >
> > > > > > - You most likely want to do something with RPi in
> > your GSoC
> > > > too. So
> > > > > > maybe some comments ("x is already done", "y
> seems to be
> > > > still open")
> > > > > > for the ticket for it would be nice too:
> > > > > https://devel.rtems.org/ticket/2899
> > > > > >
> > > > > >
> > > > > > For non raspberry topics: We have a lot of
> open bugs
> > where
> > > > everyone is
> > > > > > happy if they are closed:
> https://devel.rtems.org/query
> > > > > >
> > > > > > A lot of them might are even out of date and
> just need
> > > > someone who
> > > > > reads
> > > > > > them and asks whether they can be closed.
> > > > > >
> > > > > >>
> > > > > >>
> > > > > >>>
> > > > > >>> On Fri, Dec 27, 2019 at 5:07 PM Christian
> Mauderer
> > > > > >> <list at c-mauderer.de
> <mailto:list at c-mauderer.de> <mailto:list at c-mauderer.de
> <mailto:list at c-mauderer.de>>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>
> > > > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>>
> > > > > <mailto:list at c-mauderer.de
> <mailto:list at c-mauderer.de> <mailto:list at c-mauderer.de
> <mailto:list at c-mauderer.de>>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>
> > > > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>>>
> > > > > >>> <mailto:list at c-mauderer.de
> <mailto:list at c-mauderer.de>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>
> > > > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>>
> > > > > <mailto:list at c-mauderer.de
> <mailto:list at c-mauderer.de> <mailto:list at c-mauderer.de
> <mailto:list at c-mauderer.de>>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>
> > > > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>>>>> wrote:
> > > > > >>>
> > > > > >>> On 27/12/2019 12:20, Niteesh wrote:
> > > > > >>> > I have sent the patch. I also sent a
> > documentation
> > > > update
> > > > > >> for the
> > > > > >>> > quick-start section
> > > > > >>> > a few months ago. But no one took a
> look at
> > it. Can you
> > > > > have a
> > > > > >>> look at it?
> > > > > >>>
> > > > > >>> I'll try to have a look at it soon.
> > > > > >>>
> > > > > >>> >
> > > > > >>> >
> > > > https://www.mail-archive.com/devel@rtems.org/msg20965.html
> > > > > >>>
> > > > > >>> If you don't get any responses to a patch
> > please just
> > > > send a
> > > > > >> reminder
> > > > > >>> one or two weeks later. It's quite likely
> > that the
> > > > patch just
> > > > > >> slipped
> > > > > >>> the attention.
> > > > > >>>
> > > > > >>> Normally I leave documentation patches
> to our
> > native
> > > > speakers.
> > > > > >> They spot
> > > > > >>> a lot of errors that I won't be able to
> find.
> > > > > >>>
> > > > > >>> Can you please send a ping for the
> patch. You
> > can add
> > > > me to CC
> > > > > >> and for
> > > > > >>> this one I would suggest to CC Chris
> Johns too.
> > > > > >>>
> > > > > >>
> > > > > > _______________________________________________
> > > > > > 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>>>
> > > > <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 <mailto:devel at rtems.org>>>>
> > > > > > http://lists.rtems.org/mailman/listinfo/devel
> > > > >
> > > > > Peter
> > > > > -----------------
> > > > > Peter Dufault
> > > > > HD Associates, Inc. Software and System
> Engineering
> > > > >
> > > > > This email is delivered through the public
> internet using
> > > > protocols
> > > > > subject to interception and tampering.
> > > > >
> > > >
> > > _______________________________________________
> > > devel mailing list
> > > 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
> >
>
More information about the devel
mailing list