GSoC 2015 RPi USB Support

Joel Sherrill joel.sherrill at oarcorp.com
Thu Aug 6 20:48:36 UTC 2015



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


More information about the devel mailing list