Did you build the tests of libbsd for the xilinx_zynq_a9_qemu? Did you run and debug the telnetd01 test in Qemu to see how the device tree initialization works?
----- Yurii Shevtsov <unge...@gmail.com> schrieb: > ping > > 2015-07-01 17:20 GMT+03:00 Yurii Shevtsov <unge...@gmail.com>: > > Any news? > > > > 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. > >>> -- 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.huber at 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
