GSoC 2015 RPi USB Support
Yurii Shevtsov
ungetch at gmail.com
Thu Aug 6 20:42:33 UTC 2015
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
>>> 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