GSoC 2015 RPi USB Support
Yurii Shevtsov
ungetch at gmail.com
Thu Aug 6 21:41:04 UTC 2015
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.sherrill at 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.sherrill at oarcorp.com>:
>>>
>>>
>>>
>>> On 8/6/2015 4:16 PM, Yurii Shevtsov wrote:
>>>>
>>>>
>>>> 2015-08-07 0:08 GMT+03:00 Joel Sherrill <joel.sherrill at oarcorp.com>:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On August 6, 2015 3:57:40 PM CDT, Yurii Shevtsov <ungetch at 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.sherrill at oarcorp.com>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 8/6/2015 3:42 PM, Yurii Shevtsov wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2015-08-06 23:36 GMT+03:00 Joel Sherrill
>>>>>>
>>>>>>
>>>>>> <joel.sherrill at 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 <ungetch at 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.sherrill at 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<ungetch at 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.huber at 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<ungetch at gmail.com>:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2015-06-25 16:00 GMT+03:00 Sebastian Huber
>>>>>>>>>>>>>>>>> <sebastian.huber at 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<ungetch at 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 at 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.huber at 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.huber at embedded-brains.de
>>>>>>>>>>>>>>> PGP : Public key available on request.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne
>>>>>>
>>>>>>
>>>>>> des
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> EHUG.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> devel mailing list
>>>>>>>>>>>>> devel at 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.sherrill at 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.sherrill at 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.sherrill at 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.sherrill at OARcorp.com On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available (256) 722-9985
More information about the devel
mailing list