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