GSoC 2015 RPi USB Support
Joel Sherrill
joel.sherrill at oarcorp.com
Thu Aug 6 20:36:40 UTC 2015
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.
>> 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
More information about the devel
mailing list