Hi Yurii, For RPi USB support, can you pls try including "default-network-init.h" in the application (I tested with netshell01) instead of "default-init.h" and see if it works.
If we use default-init.h, nexus.content is empty and device is not probed. Thanks, Ragunath On Mon, Aug 10, 2015 at 7:15 AM, <devel-requ...@rtems.org> wrote: > Send devel mailing list submissions to > devel@rtems.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.rtems.org/mailman/listinfo/devel > or, via email, send a message with subject or body 'help' to > devel-requ...@rtems.org > > You can reach the person managing the list at > devel-ow...@rtems.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of devel digest..." > > > Today's Topics: > > 1. Re: GSoC 2015 RPi USB Support (Gedare Bloom) > 2. Re: GSoC 2015 RPi USB Support (Gedare Bloom) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 9 Aug 2015 19:09:53 -0400 > From: Gedare Bloom <ged...@gwu.edu> > To: Yurii Shevtsov <unge...@gmail.com> > Cc: "devel@rtems.org" <devel@rtems.org> > Subject: Re: GSoC 2015 RPi USB Support > Message-ID: > <CAC82fA0BY005smUOCk4kZpyvG8S=8znpwi5za3qz6+izlje...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > There isn't much action here on Fridays or Weekends normally. Have you > gotten around to writing up your blog post describing the various > steps you have tried? It's a little hard to help you to debug without > understanding the full scope of what you have been trying to do. > > Gedare > > On Sun, Aug 9, 2015 at 12:36 PM, Yurii Shevtsov <unge...@gmail.com> wrote: >> Ping! Any news? >> >> 2015-08-07 0:41 GMT+03:00 Yurii Shevtsov <unge...@gmail.com>: >>> These macroses are placed here >>> https://github.com/gtament/rtems-libbsd/blob/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace/rtemsbsd/include/machine/rtems-bsd-sysinit.h >>> And of course I added proper lines to specific testsuites, like >>> init01. And IRC, without this macro driver just won't be linked >>> >>> 2015-08-07 0:34 GMT+03:00 Joel Sherrill <joel.sherr...@oarcorp.com>: >>>> >>>> >>>> On 8/6/2015 4:29 PM, Yurii Shevtsov wrote: >>>>> >>>>> Isn't this line enough? >>>>> SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus) >>>> >>>> >>>> I was looking in nexus-devices.h since that is BSP specific. >>>> I wasn't expecting a generic macro. >>>> >>>> But where is that referenced? That is a macro that somewhere >>>> should be referencing so it is expanded. >>>> >>>> I would expect to see >>>> >>>> SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus) >>>> >>>> below the nexus definition in nexus-devices.h. >>>> >>>> Anyway, it is never being expanded so that definition has no impact. >>>> >>>> Whether it will work and find the right bus, is another issue >>>> but it isn't putting code in for sure. :) >>>> >>>> I have the pc386 to the point where it the RTEMS nexus device >>>> is trying to find em on the legacy bus but it is configured >>>> as being on pci. Need to run down that or trick it to work. >>>> But the probe is working. >>>> >>>> --joel >>>> >>>> >>>> >>>>> 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 >>>> >>>> >>>> -- >>>> 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 > > > ------------------------------ > > Message: 2 > Date: Sun, 9 Aug 2015 21:45:15 -0400 > From: Gedare Bloom <ged...@gwu.edu> > To: Yurii Shevtsov <unge...@gmail.com> > Cc: "devel@rtems.org" <devel@rtems.org> > Subject: Re: GSoC 2015 RPi USB Support > Message-ID: > <CAC82fA3xVJ0t6EC-DEQEunKi4C4_nrGjwVNXMH387x=o_1q...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > The one other thing I will say, to repeat myself, is that I'd like you > to clean-up your code on github so that you have clean commit history > without any merge commits. > > Gedare > > On Sun, Aug 9, 2015 at 7:09 PM, Gedare Bloom <ged...@gwu.edu> wrote: >> There isn't much action here on Fridays or Weekends normally. Have you >> gotten around to writing up your blog post describing the various >> steps you have tried? It's a little hard to help you to debug without >> understanding the full scope of what you have been trying to do. >> >> Gedare >> >> On Sun, Aug 9, 2015 at 12:36 PM, Yurii Shevtsov <unge...@gmail.com> wrote: >>> Ping! Any news? >>> >>> 2015-08-07 0:41 GMT+03:00 Yurii Shevtsov <unge...@gmail.com>: >>>> These macroses are placed here >>>> https://github.com/gtament/rtems-libbsd/blob/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace/rtemsbsd/include/machine/rtems-bsd-sysinit.h >>>> And of course I added proper lines to specific testsuites, like >>>> init01. And IRC, without this macro driver just won't be linked >>>> >>>> 2015-08-07 0:34 GMT+03:00 Joel Sherrill <joel.sherr...@oarcorp.com>: >>>>> >>>>> >>>>> On 8/6/2015 4:29 PM, Yurii Shevtsov wrote: >>>>>> >>>>>> Isn't this line enough? >>>>>> SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus) >>>>> >>>>> >>>>> I was looking in nexus-devices.h since that is BSP specific. >>>>> I wasn't expecting a generic macro. >>>>> >>>>> But where is that referenced? That is a macro that somewhere >>>>> should be referencing so it is expanded. >>>>> >>>>> I would expect to see >>>>> >>>>> SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus) >>>>> >>>>> below the nexus definition in nexus-devices.h. >>>>> >>>>> Anyway, it is never being expanded so that definition has no impact. >>>>> >>>>> Whether it will work and find the right bus, is another issue >>>>> but it isn't putting code in for sure. :) >>>>> >>>>> I have the pc386 to the point where it the RTEMS nexus device >>>>> is trying to find em on the legacy bus but it is configured >>>>> as being on pci. Need to run down that or trick it to work. >>>>> But the probe is working. >>>>> >>>>> --joel >>>>> >>>>> >>>>> >>>>>> 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 >>>>> >>>>> >>>>> -- >>>>> 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 > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > > ------------------------------ > > End of devel Digest, Vol 45, Issue 25 > ************************************* -- ragu _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
