Ping! Any news?
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?? > > 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
