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