On Sat, Jan 4, 2020 at 1:29 AM Christian Mauderer <l...@c-mauderer.de> wrote:
> On 03/01/2020 18:37, Niteesh 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. > > 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? > Can you build this version of qemu and see if USB works properly? you don't have to use RTEMS, you can use a lightweight linux distro and see if you can talk to a usb device in qemu. > > > > > > 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. > For some reason, I couldn't get it to boot using the default bootloader. I will be using u-boot since it also makes it easier for me to upload the kernel images. > > > > 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 <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
