GSoC 2015 RPi USB Support

Gedare Bloom gedare at gwu.edu
Sun Aug 9 23:09:53 UTC 2015 

There isn't much action here on Fridays or Weekends normally. Have you
gotten around to writing up your blog post describing the various
steps you have tried? It's a little hard to help you to debug without
understanding the full scope of what you have been trying to do.

Gedare

On Sun, Aug 9, 2015 at 12:36 PM, Yurii Shevtsov <ungetch at gmail.com> wrote:
> Ping! Any news?
>
> 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
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

More information about the devel mailing list