GSoC 2015 RPi USB Support
Yurii Shevtsov
ungetch at gmail.com
Thu Aug 6 21:16:54 UTC 2015
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"
>>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
More information about the devel
mailing list