GSoC 2015 RPi USB Support
Yurii Shevtsov
ungetch at gmail.com
Thu Aug 6 20:22:56 UTC 2015
Ping! Any news?
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??
>
> 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