GSoC 2015 RPi USB Support
Joel Sherrill
joel.sherrill at oarcorp.com
Thu Aug 6 21:34:42 UTC 2015
On 8/6/2015 4:29 PM, Yurii Shevtsov wrote:
> Isn't this line enough?
> SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus)
I was looking in nexus-devices.h since that is BSP specific.
I wasn't expecting a generic macro.
But where is that referenced? That is a macro that somewhere
should be referencing so it is expanded.
I would expect to see
SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus)
below the nexus definition in nexus-devices.h.
Anyway, it is never being expanded so that definition has no impact.
Whether it will work and find the right bus, is another issue
but it isn't putting code in for sure. :)
I have the pc386 to the point where it the RTEMS nexus device
is trying to find em on the legacy bus but it is configured
as being on pci. Need to run down that or trick it to work.
But the probe is working.
--joel
> 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
--
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