Isn't this line enough? SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus)
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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
