GSoC 2015 RPi USB Support
Yurii Shevtsov
ungetch at gmail.com
Mon Aug 10 22:17:53 UTC 2015
I finally found the solution. All I need is to add
#include <bsp/nexus-devices.h> to a testsuite source
Now I have a rtemsroset.bsd.nexus.content section
2015-08-07 0:41 GMT+03:00 Yurii Shevtsov <ungetch at gmail.com>:
> 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