What do you mean by "getting pulled"?
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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel