GSoC 2015 RPi USB Support

Yurii Shevtsov ungetch at gmail.com
Wed Aug 5 15:29:40 UTC 2015


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??

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
>


More information about the devel mailing list