The one other thing I will say, to repeat myself, is that I'd like you to clean-up your code on github so that you have clean commit history without any merge commits.
Gedare On Sun, Aug 9, 2015 at 7:09 PM, Gedare Bloom <ged...@gwu.edu> wrote: > 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 <unge...@gmail.com> wrote: >> Ping! Any news? >> >> 2015-08-07 0:41 GMT+03:00 Yurii Shevtsov <unge...@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.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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
