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" >>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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel