Re: [PATCH 01/02] USB driver bcm283x_dwcotg added.
Dear Deval Shah,
I found reason about "why dwcotg probe & attach function is not called".
Even though DRIVER_MODULE is declared in below, _bsd__start_set_nexus &
_bsd__stop_set_nexus is not initialized.
DRIVER_MODULE(bcm283x_dwcotg, nexus, bcm283x_dwc_otg_driver,
bcm283x_dwc_otg_devclass, 0, 0);
I checked symbol information by arm-rtems4.12-nm command.
00225fac D _bsd__start_set_nexus
00225fac D _bsd__start_set_sysctl_set
0022ca10 D _bsd__start_set_sysinit_set
0022974c D _bsd_start_softclock_sys_init
00225fac D _bsd__stop_set_modmetadata_set
00225fac D _bsd__stop_set_nexus
002260a4 D _bsd__stop_set_sysctl_set
0022cb04 D _bsd__stop_set_sysinit_set
But, I was failed for finding location for initializing
_bsd__start_set_nexus and _bsd__stop_set_nexus.
Please advise me.
Best Regards,
Thomas Kim.
2016-08-11 11:40 GMT+09:00 Thomas Kim :
> Dear Deval Shah,
>
> I found something.
>
> At this time, I am analyzing libbsd subsystem call procedure.
> I added additional information on verbose log file for referencing
> kernel.h (in rtems-libbsd/freebsd/sys/sys) and symbol file which is
> generated by arm-rtems4.12-nm.
> I attached this log file(libbsd-verbose-log.txt).
>
> As you see in this log file, my surmmary is below;
>
> 1) subsystem 31 is SI_SUB_DRIVERS. also, I checked that
> dwcotg_nexus_mod, usbus_ehci_mod, umass_uhub_mod, uhub_uhub_mod,
> uhub_usbus_mod are registered by _bsd_module_register_init().
> - I think that it is okay.
>
> 2) subsystem 380 is SI_SUB_CONFIGURE. I checked nexus_probe() in
> rtems-kernel-nexus.c is called in this phase.
> but, device_add_child() is not called in below step of nexus_probe().
>
>SET_FOREACH(nd, nexus) {
> device_add_child(dev, nd->name, nd->unit);
>}
>
> Finally, I am guessing that device_add_child() for DWCOTG should be called.
> At this time, I don't know why device_add_child() for DWCOTG controller is
> not called.
>
> Please advise me.
>
> Best Regards,
> Thomas Kim
>
>
> 2016-08-11 8:51 GMT+09:00 Thomas Kim :
>
>> Dear Deval Shah,
>>
>> I checked my rasberry board. my board is rasberry Pi B+. (It is not RPI2
>> B+)
>> I am sorry. I returned to rtems, libbsd version for Pi B+.
>>
>> Anyway, I guess that both bcm283x_dwc_otg_probe() and
>> bcm283x_dwc_otg_attach() function should be called.
>> I don't know how to call bcm283x_dwc_otg_probe() and
>> bcm283x_dwc_otg_attach().
>>
>> Please advsie me.
>>
>> Best Regards,
>> Thomas Kim.
>>
>> 2016-08-10 22:06 GMT+09:00 Deval Shah :
>>
>>> I saw the files which you have attached. I found one quick mistake.
>>>
>>> In your nexus-devices.h file "RTEMS_BSD_DRIVER_BCM283X_DWCOTG(0x2098,
>>> 17);", base and irq used are wrong. I had corrected the irq in my other
>>> commit. They will be 0x3F98 (since you are using Raspberry pi 2) and 9.
>>>
>>> It would be easier to use the macros. i.e.
>>> RTEMS_BSD_DRIVER_BCM283X_DWCOTG(BCM2835_USB_BASE, BCM2835_IRQ_ID_USB);
>>>
>>>
>>> ᐧ
>>>
>>> On Wed, Aug 10, 2016 at 1:11 PM, Thomas Kim
>>> wrote:
>>>
Dear Deval Shah,
Thank you very much for your reply.
I checked this again.
Because there is not your code in currrent git system, I patched your
code in current libbsd code.
As I know in current libbsd source tree, your nexus_devices.h should be
sperated into rtems-bsd-nexus-bus.h. I attached this.
First of all, I completed to test RTEMS testsuites/sample/ticker.exe on
RPI2 B+ board.
I am tring to test rtems-libbsd/rtemsbsd/testsuite/usb01.
also, I try to test two cases in usb01/init.c
case 1 does not include NEED_USB_EHCI. case 2 include NEED_USB_EHCI.
#if defined(LIBBSP_ARM_LPC24XX_BSP_H) || defined(LIBBSP_ARM_LPC32XX_BSP
_H)
#define NEED_USB_OHCI
(CASE1) #elif defined(__GEN83xx_BSP_h) || defined(LIBBSP_POWERPC_QORIQ_B
SP_H)
(CASE2) #elif defined(__GEN83xx_BSP_h) || defined(LIBBSP_ARM_RASPBERRYPI
_BSP_H)
#define NEED_USB_EHCI
#endif
SYSINIT_NEED_USB_CORE;
#ifdef NEED_USB_OHCI
SYSINIT_NEED_USB_OHCI;
#endif
#ifdef NEED_USB_EHCI
SYSINIT_NEED_USB_EHCI;
#endif
also, I added "#define VERBOSE_SYSINIT 1" in init_main.c for checking
SYS_INIT functional call.
At this time, usb_quirk_init() only is called when I test two cases.
I attached serial log file, too.
Please let me know my missing point.
Best Regards,
JunBeom
2016-08-10 5:31 GMT+09:00 Deval Shah :
> Hello Thomas Kim,
>
> It is the same code which you downloaded will work for the raspberry
> pi. You can test the libbsd version of raspberry pi by configuring waf
> with
> the following arguments.
>
> waf configure --prefix=/opt/rtems/4.12/bsps \
> --rtems=/opt/rtems/4.12/bsps \
> --rtems-tools=/opt/rtems/4.12/tools \
> --rtems-bsps=arm/raspberrypi
>
> You can find more at this link. https://git.rtems.org/rt
> ems-libbsd/tre
Re: RSB toolchain builds on Windows 10/Windows Subsystem for Linux
Sure. I did not take any notes when I did the first install and build, I'm going to reinstall the linux environment and document what I had to do. Alan On Tue, Aug 9, 2016 at 8:06 PM, Chris Johns wrote: > On 09/08/2016 23:51, Alan Cudmore wrote: > >> I thought I would try the new Windows Subsystem for Linux to see how the >> RSB toolchain build would go. >> WSL is a port of the Ubuntu 14.04 user space binaries to the windows 10 >> kernel: >> https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux >> >> The RSB toolchain builds the same here as it does on a native ubuntu >> 14.04 machine. No problems or differences that I can tell. >> >> Note that I'm not advocating this, just reporting another option for >> RTEMS developers :) >> >> > Could you please update the doc in the RSB to mention this? > > Thanks > Chris > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 01/02] USB driver bcm283x_dwcotg added.
Dear Deval Shah,
I found email thread(name: GSoC 2015 RPi USB Support) which is related with
my problem.
https://lists.rtems.org/pipermail/devel/2015-August/012218.html
Because rtems and libbsd version is not matched with last year version,
some description is not matched. but, this email thread's problem is same
with my case.
On referencing, I attached my modified code.
At this time, even though I changed according to GSoC 2015 RPi USB Support,
my problem is not resolved.
Current my idea is that I should modify linkscript for resolving this as
like below example.
.rtemsroset : ALIGN_WITH_INPUT {
/* Special FreeBSD linker set sections */
__start_set_sysctl_set = .;
*(set_sysctl_*);
__stop_set_sysctl_set = .;
*(set_domain_*);
*(set_pseudo_*);
#if 1 // Thomas added
__start_set_nexus = .;
/* some description should be added in here */
__stop_set_nexus = .;
#endif
...
But, I don't know that which description should be addded between
__start_set_nexus and __stop_set_nexus.
Is this right method ?
Please advise me.
Best Regards.
Thomas Kim
2016-08-11 19:01 GMT+09:00 Thomas Kim :
> Dear Deval,
>
> No problem.
>
> If I find addtional something, I will let you know.
>
> Best Regards,
> Thomas Kim
>
> 2016-08-11 18:57 GMT+09:00 Deval Shah :
>
>> Hello Thomas Kim,
>>
>> I am actually going out of station for a week. I will look when I get
>> some time.
>>
>> Sorry for not being able to help immediately.
>>
>> Deval Shah
>>
>> On Thursday 11 August 2016, Thomas Kim wrote:
>>
>>> Dear Deval Shah,
>>>
>>> I found reason about "why dwcotg probe & attach function is not called".
>>>
>>> Even though DRIVER_MODULE is declared in below, _bsd__start_set_nexus &
>>> _bsd__stop_set_nexus is not initialized.
>>>
>>> DRIVER_MODULE(bcm283x_dwcotg, nexus, bcm283x_dwc_otg_driver,
>>> bcm283x_dwc_otg_devclass, 0, 0);
>>>
>>> I checked symbol information by arm-rtems4.12-nm command.
>>>
>>> 00225fac D _bsd__start_set_nexus
>>> 00225fac D _bsd__start_set_sysctl_set
>>> 0022ca10 D _bsd__start_set_sysinit_set
>>> 0022974c D _bsd_start_softclock_sys_init
>>> 00225fac D _bsd__stop_set_modmetadata_set
>>> 00225fac D _bsd__stop_set_nexus
>>> 002260a4 D _bsd__stop_set_sysctl_set
>>> 0022cb04 D _bsd__stop_set_sysinit_set
>>>
>>> But, I was failed for finding location for initializing
>>> _bsd__start_set_nexus and _bsd__stop_set_nexus.
>>>
>>> Please advise me.
>>>
>>> Best Regards,
>>> Thomas Kim.
>>>
>>> 2016-08-11 11:40 GMT+09:00 Thomas Kim :
>>>
Dear Deval Shah,
I found something.
At this time, I am analyzing libbsd subsystem call procedure.
I added additional information on verbose log file for referencing
kernel.h (in rtems-libbsd/freebsd/sys/sys) and symbol file which is
generated by arm-rtems4.12-nm.
I attached this log file(libbsd-verbose-log.txt).
As you see in this log file, my surmmary is below;
1) subsystem 31 is SI_SUB_DRIVERS. also, I checked that
dwcotg_nexus_mod, usbus_ehci_mod, umass_uhub_mod, uhub_uhub_mod,
uhub_usbus_mod are registered by _bsd_module_register_init().
- I think that it is okay.
2) subsystem 380 is SI_SUB_CONFIGURE. I checked nexus_probe() in
rtems-kernel-nexus.c is called in this phase.
but, device_add_child() is not called in below step of nexus_probe().
SET_FOREACH(nd, nexus) {
device_add_child(dev, nd->name, nd->unit);
}
Finally, I am guessing that device_add_child() for DWCOTG should be
called.
At this time, I don't know why device_add_child() for DWCOTG controller
is not called.
Please advise me.
Best Regards,
Thomas Kim
2016-08-11 8:51 GMT+09:00 Thomas Kim :
> Dear Deval Shah,
>
> I checked my rasberry board. my board is rasberry Pi B+. (It is not
> RPI2 B+)
> I am sorry. I returned to rtems, libbsd version for Pi B+.
>
> Anyway, I guess that both bcm283x_dwc_otg_probe() and
> bcm283x_dwc_otg_attach() function should be called.
> I don't know how to call bcm283x_dwc_otg_probe() and
> bcm283x_dwc_otg_attach().
>
> Please advsie me.
>
> Best Regards,
> Thomas Kim.
>
> 2016-08-10 22:06 GMT+09:00 Deval Shah :
>
>> I saw the files which you have attached. I found one quick mistake.
>>
>> In your nexus-devices.h file "RTEMS_BSD_DRIVER_BCM283X_DWCOTG(0x2098,
>> 17);", base and irq used are wrong. I had corrected the irq in my
>> other commit. They will be 0x3F98 (since you are using Raspberry pi
>> 2)
>> and 9.
>>
>> It would be easier to use the macros. i.e.
>> RTEMS_BSD_DRIVER_BCM283X_DWCOTG(BCM2835_USB_BASE, BCM2835_IRQ_ID_USB
>> );
>>
>>
>> ᐧ
>>
>> On Wed, Aug 10, 2016 at 1:11 PM, Thomas Kim
>> wrote:
>>
>>> Dear Deval Shah,
>>>
>>> Thank you very much for your reply.
>>> I checked this again.
>>
