These macroses are placed here https://github.com/gtament/rtems-libbsd/blob/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace/rtemsbsd/include/machine/rtems-bsd-sysinit.h And of course I added proper lines to specific testsuites, like init01. And IRC, without this macro driver just won't be linked
2015-08-07 0:34 GMT+03:00 Joel Sherrill <joel.sherr...@oarcorp.com>: > > > On 8/6/2015 4:29 PM, Yurii Shevtsov wrote: >> >> Isn't this line enough? >> SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus) > > > I was looking in nexus-devices.h since that is BSP specific. > I wasn't expecting a generic macro. > > But where is that referenced? That is a macro that somewhere > should be referencing so it is expanded. > > I would expect to see > > SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus) > > below the nexus definition in nexus-devices.h. > > Anyway, it is never being expanded so that definition has no impact. > > Whether it will work and find the right bus, is another issue > but it isn't putting code in for sure. :) > > I have the pc386 to the point where it the RTEMS nexus device > is trying to find em on the legacy bus but it is configured > as being on pci. Need to run down that or trick it to work. > But the probe is working. > > --joel > > > >> 2015-08-07 0:23 GMT+03:00 Joel Sherrill <joel.sherr...@oarcorp.com>: >>> >>> >>> >>> On 8/6/2015 4:16 PM, Yurii Shevtsov wrote: >>>> >>>> >>>> 2015-08-07 0:08 GMT+03:00 Joel Sherrill <joel.sherr...@oarcorp.com>: >>>>> >>>>> >>>>> >>>>> >>>>> On August 6, 2015 3:57:40 PM CDT, Yurii Shevtsov <unge...@gmail.com> >>>>> wrote: >>>>>> >>>>>> >>>>>> What do you mean by "getting pulled"? >>>>> >>>>> >>>>> >>>>> >>>>> As I understood things, you had a linked executable but an empty >>>>> section. >>>>> Just curious if your devices were showing up at all. >>>> >>>> >>>> >>>> Yes, exactly. If you mean is probe function being executed, the answer >>>> is >>>> ''no" >>> >>> >>> >>> You have to associate the drivers with a nexus bus. Something like this >>> >>> SYSINIT_DRIVER_REFERENCE(mmc, dw_mmc); >>> SYSINIT_DRIVER_REFERENCE(mmcsd, mmc); >>> >>> That's from the Altera Cyclone. >>> >>> You only configured a nexus device and didn't hang anything off it. >>> >>> >>>>>> 2015-08-06 23:48 GMT+03:00 Joel Sherrill <joel.sherr...@oarcorp.com>: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 8/6/2015 3:42 PM, Yurii Shevtsov wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2015-08-06 23:36 GMT+03:00 Joel Sherrill >>>>>> >>>>>> >>>>>> <joel.sherr...@oarcorp.com>: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 8/6/2015 3:22 PM, Yurii Shevtsov wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Ping! Any news? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The people with experience with the libbsd code is quite small. :( >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2015-08-05 18:29 GMT+03:00 Yurii Shevtsov <unge...@gmail.com>: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The problem is that rtemsroset.bsd.nexus.content doesn't exist in >>>>>>>>>>> final elf. If I change driver's name in >>>>>> >>>>>> >>>>>> RTEMS_BSD_DEFINE_NEXUS_DEVICE >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> macro, linker will throw an error >>>>>>>>>>> (.rtemsroset.bsd.nexus.content+0x10): undefined reference to >>>>>> >>>>>> >>>>>> '%wrong >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> driver's name%'. Otherwise with correct name - no >>>>>> >>>>>> >>>>>> errors(warnings) and >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> no nexus.content section. How can you explain this?? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The RTEMS_BSD_DEFINE_NEXUS_DEVICE() macro must reference a >>>>>> >>>>>> >>>>>> bus/mexus, >>>>>>>>> >>>>>>>>> >>>>>>>>> not a regular device driver. I would expect a nexus device for the >>>>>> >>>>>> >>>>>> Pi >>>>>>>>> >>>>>>>>> >>>>>>>>> to be in >>>>>>>>> >>>>>> >>>>>> https://github.com/freebsd/freebsd/tree/master/sys/arm/broadcom/bcm2835 >>>>>>>>> >>>>>>>>> >>>>>>>>> or pointed to by a file in there. >>>>>>>>> >>>>>>>>> Look at the configuration for the various bsps in nexus-devices.h >>>>>> >>>>>> >>>>>> and >>>>>>>>> >>>>>>>>> >>>>>>>>> then at the source the macros refer to. >>>>>>>>> >>>>>>>>> Raspberry Pi source will have to be imported from the FreeBSD tree. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Of course, I did it!) >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> https://github.com/gtament/rtems-libbsd/commit/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Is bcm283x_dwcotg* getting pulled into your build? >>>>>>> >>>>>>> >>>>>>>>>>> 2015-08-02 18:02 GMT+03:00 Joel Sherrill >>>>>> >>>>>> >>>>>> <joel.sherr...@oarcorp.com>: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 08/01/2015 04:00 PM, Yurii Shevtsov wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> During debugging of compiled Nexus module(driver) I found out >>>>>> >>>>>> >>>>>> that >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> content which suppose to be created in >>>>>> >>>>>> >>>>>> RTEMS_BSD_DEFINE_SET(nexus, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> rtems_bsd_device) is empty, That should mean that either it is >>>>>> >>>>>> >>>>>> not >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> found or cannot be read. Please, let me know why empty content >>>>>> >>>>>> >>>>>> is not >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> create any error message and in what situation it can be empty. >>>>>>>>>>>>> >>>>>>>>>>>> Sebastian just added the pc386 to the nexus-devices file. Make >>>>>> >>>>>> >>>>>> sure >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> the bsp.h is tripping the conditional logic in that file to get >>>>>> >>>>>> >>>>>> the Pi >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> path as a minimum. >>>>>>>>>>>> >>>>>>>>>>>> Then you are going to need to add the appropriate devices for Pi >>>>>>>>>>>> USB. If the Pi doesn't have one of the standard USB >>>>>> >>>>>> >>>>>> controllers, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> then >>>>>>>>>>>> you will have to import the source for it from FreeBSD. >>>>>>>>>>>> >>>>>>>>>>>> The pc386 is stuck at the point where it detects the NIC >>>>>> >>>>>> >>>>>> configured >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> but needs resources. I am going to try to debug that. >>>>>>>>>>>> >>>>>>>>>>>>> 2015-06-29 19:50 GMT+03:00 Yurii Shevtsov<unge...@gmail.com>: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> So, it is empty. >>>>>>>>>>>>>> >>>>>>>>>>>>>> .rtemsroset.bsd.nexus.begin >>>>>>>>>>>>>> 0x001104bc 0x0 >>>>>>>>>>>>>> ./libbsd.a(rtems-bsd-nexus.c.16.o) >>>>>>>>>>>>>> 0x001104bc >>>>>> >>>>>> >>>>>> _bsd__start_set_nexus >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> .rtemsroset.bsd.nexus.end >>>>>>>>>>>>>> 0x001104bc 0x0 >>>>>>>>>>>>>> ./libbsd.a(rtems-bsd-nexus.c.16.o) >>>>>>>>>>>>>> 0x001104bc >>>>>> >>>>>> >>>>>> _bsd__stop_set_nexus >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> What will be next step? My repo: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> >>>>>> >>>>>> https://github.com/gtament/rtems-libbsd/commit/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2015-06-29 9:43 GMT+03:00 Sebastian >>>>>>>>>>>>>> Huber<sebastian.hu...@embedded-brains.de>: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You can debug this issue on Qemu. The Nexus childes are >>>>>> >>>>>> >>>>>> registered >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> in >>>>>>>>>>>>>>> a >>>>>>>>>>>>>>> linker set, so I would consult the linker map file. It >>>>>> >>>>>> >>>>>> should look >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> like >>>>>>>>>>>>>>> this: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> .rtemsroset.bsd.nexus.begin >>>>>>>>>>>>>>> 0x000000000052ef7c 0x0 >>>>>>>>>>>>>>> libbsd.a(rtems-bsd-nexus.o) >>>>>>>>>>>>>>> 0x000000000052ef7c _bsd__start_set_nexus >>>>>>>>>>>>>>> .rtemsroset.bsd.nexus.content >>>>>>>>>>>>>>> 0x000000000052ef7c 0x28 >>>>>>>>>>>>>>> testsuite/telnetd01/test_main.o >>>>>>>>>>>>>>> .rtemsroset.bsd.nexus.end >>>>>>>>>>>>>>> 0x000000000052efa4 0x0 >>>>>>>>>>>>>>> libbsd.a(rtems-bsd-nexus.o) >>>>>>>>>>>>>>> 0x000000000052efa4 _bsd__stop_set_nexus >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The .rtemsroset.bsd.nexus.content section must be non-empty. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 27/06/15 16:39, Yurii Shevtsov wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Any ideas? Maybe I did some typo? Maybe you can compile and >>>>>> >>>>>> >>>>>> try it >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>> qemu? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2015-06-26 17:05 GMT+03:00 Yurii >>>>>> >>>>>> >>>>>> Shevtsov<unge...@gmail.com>: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2015-06-25 16:00 GMT+03:00 Sebastian Huber >>>>>>>>>>>>>>>>> <sebastian.hu...@embedded-brains.de>: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I would set a break point to nexus_probe(). In this loop >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> SET_FOREACH(nd, nexus) { >>>>>>>>>>>>>>>>>> device_add_child(dev, nd->name, nd->unit); >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> your device must get added. I would also set break points >>>>>> >>>>>> >>>>>> to the >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> probe >>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>> attach functions of your device. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Added printfs() >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> printf("before setforeach\n"); >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> SET_FOREACH(nd, nexus) { >>>>>>>>>>>>>>>>> printf("setforeach: %s\n", nd->name); >>>>>>>>>>>>>>>>> device_add_child(dev, nd->name, nd->unit); >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Got only 'before setforeach' in console. So it doesn't step >>>>>> >>>>>> >>>>>> into >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> loop. >>>>>>>>>>>>>>>>> Any ideas? Also I already had printfs in my driver's probe >>>>>> >>>>>> >>>>>> and >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> attach, >>>>>>>>>>>>>>>>> also got no output. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 25/06/15 14:50, Yurii Shevtsov wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This is ping message, with small update: the problem is >>>>>> >>>>>> >>>>>> not on >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> linking stage, driver is linked to testsuite (checked >>>>>> >>>>>> >>>>>> with >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> objdump) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2015-06-21 17:57 GMT+03:00 Yurii >>>>>> >>>>>> >>>>>> Shevtsov<unge...@gmail.com>: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hello) >>>>>>>>>>>>>>>>>>>> Now I have apps from libbsd testsuite running. But DWC >>>>>> >>>>>> >>>>>> OTG >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> driver >>>>>>>>>>>>>>>>>>>> doesn't >>>>>>>>>>>>>>>>>>>> loads. >>>>>>>>>>>>>>>>>>>> I added this lines to init01/test_main.c: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> +SYSINIT_NEED_USB_CORE; >>>>>>>>>>>>>>>>>>>> +SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus); >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> (I know it's bad hardcode) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> If I run it. I get only this: >>>>>>>>>>>>>>>>>>>> nexus0:<RTEMS Nexus device> >>>>>>>>>>>>>>>>>>>> devctl: +nexus0 at on root0 >>>>>>>>>>>>>>>>>>>> devctl: !system=IFNET subsystem=lo0 type=ATTACH >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Of course, I modified >>>>>>>>>>>>>>>>>>>> rtemsbsd/include/machine/rtems-bsd-sysinit.h >>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>> rtemsbsd/include/bsp/nexus-devices.h (took vlues from >>>>>> >>>>>> >>>>>> working >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> DTS) >>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>> did other nexus-related changes to drivers. You can find >>>>>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>> my >>>>>>>>>>>>>>>>>>>> repo https://github.com/gtament/rtems-libbsd/ >>>>>>>>>>>>>>>>>>>> So I need some kind of code review, please. >>>>>>>>>>>>>>>>>>>> P.S. All testsuites (netshell01, usb01) with shell hangs >>>>>>>>>>>>>>>>>>>> without >>>>>>>>>>>>>>>>>>>> any >>>>>>>>>>>>>>>>>>>> output. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks in advance! >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> devel mailing list >>>>>>>>>>>>>>>>>>> devel@rtems.org >>>>>>>>>>>>>>>>>>> http://lists.rtems.org/mailman/listinfo/devel >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Sebastian Huber, embedded brains GmbH >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Address : Dornierstr. 4, D-82178 Puchheim, Germany >>>>>>>>>>>>>>>>>> Phone : +49 89 189 47 41-16 >>>>>>>>>>>>>>>>>> Fax : +49 89 189 47 41-09 >>>>>>>>>>>>>>>>>> E-Mail : sebastian.hu...@embedded-brains.de >>>>>>>>>>>>>>>>>> PGP : Public key available on request. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Diese Nachricht ist keine geschäftliche Mitteilung im >>>>>> >>>>>> >>>>>> Sinne des >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> EHUG. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Sebastian Huber, embedded brains GmbH >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Address : Dornierstr. 4, D-82178 Puchheim, Germany >>>>>>>>>>>>>>> Phone : +49 89 189 47 41-16 >>>>>>>>>>>>>>> Fax : +49 89 189 47 41-09 >>>>>>>>>>>>>>> E-Mail : sebastian.hu...@embedded-brains.de >>>>>>>>>>>>>>> PGP : Public key available on request. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne >>>>>> >>>>>> >>>>>> des >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> EHUG. >>>>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> devel mailing list >>>>>>>>>>>>> devel@rtems.org >>>>>>>>>>>>> http://lists.rtems.org/mailman/listinfo/devel >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> -- Joel Sherrill >>>>>>>>>>>> Ask me about RTEMS: a free RTOS >>>>>>>>>>>> Support and Training Available >>>>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Joel Sherrill, Ph.D. Director of Research & Development >>>>>>>>> joel.sherr...@oarcorp.com On-Line Applications Research >>>>>>>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >>>>>>>>> Support Available (256) 722-9985 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Joel Sherrill, Ph.D. Director of Research & Development >>>>>>> joel.sherr...@oarcorp.com On-Line Applications Research >>>>>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >>>>>>> Support Available (256) 722-9985 >>>>> >>>>> >>>>> >>>>> --joel >>> >>> >>> >>> -- >>> Joel Sherrill, Ph.D. Director of Research & Development >>> joel.sherr...@oarcorp.com On-Line Applications Research >>> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >>> Support Available (256) 722-9985 > > > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@oarcorp.com On-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available (256) 722-9985 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel