GSoC 2015 RPi USB Support
Joel Sherrill
joel.sherrill at oarcorp.com
Thu Aug 6 21:23:31 UTC 2015
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