On Sat, Jan 4, 2020 at 3:34 AM Christian Mauderer <l...@c-mauderer.de> wrote:
> On 03/01/2020 20:17, Niteesh wrote: > > Finally, I am able to load IMAGES into Rpi3 using u-boot. But didn't > > check whether FDT works. I added the AUX driver from my bare-metal > > project for testing. I'll replace it with NS16550 soon. > > I loaded the fileio example and it prints the board information. Below > > is the link to the screenshot > > https://ibb.co/cJbFHqz > > That's a great start. > > > But it's stuck there, maybe an exception was raised because I didn't > > modify the address for another device but not sure! Can you think of > > something > > which could have caused it? > > Exceptions should print an exception frame. So I'm not sure whether that > is the case. Do you have some JTAG adapter that would work with OpenOCD > or simmilar? > I dont have a JTAG. I going to fallback to printfs. I going to stick printf in various places and see where it hangs. Do you have any other ideas? Can we use GDB? > > > > > > On Fri, Jan 3, 2020 at 11:07 PM Niteesh <gsnb...@gmail.com > > <mailto:gsnb...@gmail.com>> wrote: > > > > On Fri, Jan 3, 2020 at 7:30 PM Christian Mauderer > > <l...@c-mauderer.de <mailto:l...@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. > > > > Christian, can you check out > > this https://github.com/0xabu/qemu/wiki it partially supports > > USB, can you give it a try? > > > > > > 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. > > > > 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. > > > > 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 <ged...@rtems.org > > <mailto:ged...@rtems.org> > > > <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>> wrote: > > > > > > On Mon, Dec 30, 2019 at 2:47 PM Christian Mauderer > > > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> wrote: > > > > > > > > On 30/12/2019 15:45, Niteesh wrote: > > > > > On Mon, Dec 30, 2019 at 7:14 PM Christian Mauderer > > > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>> wrote: > > > > > > > > > > On 30/12/2019 07:25, Niteesh wrote: > > > > > > > > > > > > > > > > > > On Mon, Dec 30, 2019 at 4:44 AM Peter Dufault > > > <dufa...@hda.com <mailto:dufa...@hda.com> > > <mailto:dufa...@hda.com <mailto:dufa...@hda.com>> > > > > > <mailto:dufa...@hda.com <mailto:dufa...@hda.com> > > <mailto:dufa...@hda.com <mailto:dufa...@hda.com>>> > > > > > > <mailto:dufa...@hda.com <mailto:dufa...@hda.com> > > <mailto:dufa...@hda.com <mailto:dufa...@hda.com>> > > > <mailto:dufa...@hda.com <mailto:dufa...@hda.com> > > <mailto:dufa...@hda.com <mailto:dufa...@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 > > > > > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > > > > <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>>> > wrote: > > > > > > > > > > > > > > On 28/12/2019 07:12, Niteesh wrote: > > > > > > >> > > > > > > >> > > > > > > >> On Sat, 28 Dec, 2019, 3:51 AM Christian > > Mauderer, > > > > > > <l...@c-mauderer.de > > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > > > <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>> > > > > > > >> <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > > > <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@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 > > > > > > >> <l...@c-mauderer.de > > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > > > <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>> > > > > > > <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > > > <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>>> > > > > > > >>> <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > > > <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>> > > > > > > <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > > > <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > > <mailto:l...@c-mauderer.de>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@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@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>>> > > > > > <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 <mailto:devel@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@rtems.org <mailto:devel@rtems.org> > > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > > > > http://lists.rtems.org/mailman/listinfo/devel > > > > > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel