devel Digest, Vol 45, Issue 25
ragu nath
ragunath3252 at gmail.com
Mon Aug 10 21:37:15 UTC 2015
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-request at rtems.org> wrote:
> Send devel mailing list submissions to
> devel at 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-request at rtems.org
>
> You can reach the person managing the list at
> devel-owner at 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 <gedare at gwu.edu>
> To: Yurii Shevtsov <ungetch at gmail.com>
> Cc: "devel at rtems.org" <devel at rtems.org>
> Subject: Re: GSoC 2015 RPi USB Support
> Message-ID:
> <CAC82fA0BY005smUOCk4kZpyvG8S=8znpwi5za3QZ6+izLJEf_g at 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 <ungetch at gmail.com> wrote:
>> Ping! Any news?
>>
>> 2015-08-07 0:41 GMT+03:00 Yurii Shevtsov <ungetch at 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.sherrill at 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.sherrill at oarcorp.com>:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 8/6/2015 4:16 PM, Yurii Shevtsov wrote:
>>>>>>>
>>>>>>>
>>>>>>> 2015-08-07 0:08 GMT+03:00 Joel Sherrill <joel.sherrill at oarcorp.com>:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On August 6, 2015 3:57:40 PM CDT, Yurii Shevtsov <ungetch at 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.sherrill at oarcorp.com>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 8/6/2015 3:42 PM, Yurii Shevtsov wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2015-08-06 23:36 GMT+03:00 Joel Sherrill
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <joel.sherrill at 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 <ungetch at 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.sherrill at 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<ungetch at 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.huber at 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<ungetch at gmail.com>:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2015-06-25 16:00 GMT+03:00 Sebastian Huber
>>>>>>>>>>>>>>>>>>>> <sebastian.huber at 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<ungetch at 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 at 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.huber at 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 at 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.sherrill at 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.sherrill at 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.sherrill at 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.sherrill at 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 at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 9 Aug 2015 21:45:15 -0400
> From: Gedare Bloom <gedare at gwu.edu>
> To: Yurii Shevtsov <ungetch at gmail.com>
> Cc: "devel at rtems.org" <devel at rtems.org>
> Subject: Re: GSoC 2015 RPi USB Support
> Message-ID:
> <CAC82fA3xVJ0t6EC-DEQEunKi4C4_nrGjwVNXMH387x=O_1qZOw at 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 <gedare at 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 <ungetch at gmail.com> wrote:
>>> Ping! Any news?
>>>
>>> 2015-08-07 0:41 GMT+03:00 Yurii Shevtsov <ungetch at 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.sherrill at 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.sherrill at oarcorp.com>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 8/6/2015 4:16 PM, Yurii Shevtsov wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> 2015-08-07 0:08 GMT+03:00 Joel Sherrill <joel.sherrill at oarcorp.com>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On August 6, 2015 3:57:40 PM CDT, Yurii Shevtsov <ungetch at 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.sherrill at oarcorp.com>:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 8/6/2015 3:42 PM, Yurii Shevtsov wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2015-08-06 23:36 GMT+03:00 Joel Sherrill
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <joel.sherrill at 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 <ungetch at 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.sherrill at 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<ungetch at 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.huber at 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<ungetch at gmail.com>:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2015-06-25 16:00 GMT+03:00 Sebastian Huber
>>>>>>>>>>>>>>>>>>>>> <sebastian.huber at 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<ungetch at 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 at 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.huber at 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 at 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.sherrill at 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.sherrill at 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.sherrill at 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.sherrill at 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 at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
> ------------------------------
>
> End of devel Digest, Vol 45, Issue 25
> *************************************
--
ragu
More information about the devel
mailing list