GSoC 2015 RPi USB Support

Yurii Shevtsov ungetch at gmail.com
Thu Aug 6 21:29:07 UTC 2015


Isn't this line enough?
SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus)

2015-08-07 0:23 GMT+03:00 Joel Sherrill <joel.sherrill at oarcorp.com>:
>
>
> On 8/6/2015 4:16 PM, Yurii Shevtsov wrote:
>>
>> 2015-08-07 0:08 GMT+03:00 Joel Sherrill <joel.sherrill at oarcorp.com>:
>>>
>>>
>>>
>>> On August 6, 2015 3:57:40 PM CDT, Yurii Shevtsov <ungetch at gmail.com>
>>> wrote:
>>>>
>>>> What do you mean by "getting pulled"?
>>>
>>>
>>>
>>> As I understood things, you had a linked executable but an empty section.
>>> Just curious if your devices were showing up at all.
>>
>>
>> Yes, exactly. If you mean is probe function being executed, the answer is
>> ''no"
>
>
> You have to associate the drivers with a nexus bus.  Something like this
>
> SYSINIT_DRIVER_REFERENCE(mmc, dw_mmc);
> SYSINIT_DRIVER_REFERENCE(mmcsd, mmc);
>
> That's from the Altera Cyclone.
>
> You only configured a nexus device and didn't hang anything off it.
>
>
>>>> 2015-08-06 23:48 GMT+03:00 Joel Sherrill <joel.sherrill at oarcorp.com>:
>>>>>
>>>>>
>>>>>
>>>>> 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
>>>
>>>
>>> --joel
>
>
> --
> 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