Re: GSOC 2017 RTEMS-libbsd issue
Am 20.04.2017 um 04:02 schrieb Sichen Zhao: > Hi Christian Mauderer, > > Ok, i got your idea,I will try it. > > Thank you for your patient for my problem. > > > Best regards > > Sichen Zhao > Hello Sichen Zhao, no problem. Don't hesitate to ask if there are any further questions or problems. Kind regards Christian Mauderer -- embedded brains GmbH Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2017 RTEMS-libbsd issue
Hi Christian Mauderer, Ok, i got your idea,I will try it. Thank you for your patient for my problem. Best regards Sichen Zhao From: Christian Mauderer <christian.maude...@embedded-brains.de> Sent: Wednesday, April 19, 2017 11:05 PM To: 赵 思晨 Cc: RTEMS Subject: Re: GSOC 2017 RTEMS-libbsd issue - Ursprüngliche Mail - > Von: "赵 思晨" <zsc19940...@outlook.com> > An: "Christian Mauderer" <christian.maude...@embedded-brains.de>, "RTEMS" > <devel@rtems.org> > Gesendet: Mittwoch, 19. April 2017 16:41:20 > Betreff: Re: GSOC 2017 RTEMS-libbsd issue > Hi Christian Mauderer, > > 1. I haven't put these change in my git repo yet. > > 2.Yes, i verified that by the console output , the below snapshot : > > > including some debug info. just forget it. > > > [cid:4fb54908-2ff4-4098-9f94-6f2aa529babf] > > > 3.The application i use is testsuite/usb01, i debug it, and it loop at the > uhub_explore function in usb_hub.c, and didn't reach the umass_probe function. > > > 4. I noticed that the pin USB1_DRVVBUS and USBx_VBUSIN is always low, so i > think > it can't detect the new device. > > > Best Regards > > Sichen Zhao > > Hello Sichen Zhao, point 4 sounds like you found your problem. According to the schematics, there is a TPS2051 on the BBB to switch the power of the USB. This chip has an active high enable input. So USB1_DRVVBUS should be high. For a quick try, you could connect a self powered hub. But sooner or later, you should just switch the pin on. Please note that it might would be a good idea to use it to reset the connected devices on a reboot. Kind regards Christian -- embedded brains GmbH Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2017 RTEMS-libbsd issue
- Ursprüngliche Mail - > Von: "赵 思晨" <zsc19940...@outlook.com> > An: "Christian Mauderer" <christian.maude...@embedded-brains.de>, "RTEMS" > <devel@rtems.org> > Gesendet: Mittwoch, 19. April 2017 16:41:20 > Betreff: Re: GSOC 2017 RTEMS-libbsd issue > Hi Christian Mauderer, > > 1. I haven't put these change in my git repo yet. > > 2.Yes, i verified that by the console output , the below snapshot : > > > including some debug info. just forget it. > > > [cid:4fb54908-2ff4-4098-9f94-6f2aa529babf] > > > 3.The application i use is testsuite/usb01, i debug it, and it loop at the > uhub_explore function in usb_hub.c, and didn't reach the umass_probe function. > > > 4. I noticed that the pin USB1_DRVVBUS and USBx_VBUSIN is always low, so i > think > it can't detect the new device. > > > Best Regards > > Sichen Zhao > > Hello Sichen Zhao, point 4 sounds like you found your problem. According to the schematics, there is a TPS2051 on the BBB to switch the power of the USB. This chip has an active high enable input. So USB1_DRVVBUS should be high. For a quick try, you could connect a self powered hub. But sooner or later, you should just switch the pin on. Please note that it might would be a good idea to use it to reset the connected devices on a reboot. Kind regards Christian -- embedded brains GmbH Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2017 RTEMS-libbsd issue
Hello Sichen Zhao, Sorry for the delayed response. Somehow the mail must have been lost. I only received it through the answer from Kevin Kirspel. I slightly changed my mailing list settings so the next time it will (hopefully) work. > > Hi Christian Mauderer, Hi all, > > > > I understand what you mean, i will update my RTEMS-libbsd to the newest > branch. > Good. > I already pull over the host controller driver files（am335x_musb.c > am335x_usbss.c umass.c）from freebsd and make them compilable in > rtems-libbsd. The umass.c is driver for storage device. > > And i already add the host controller and driver to > nexus-devices.h(RTEMS_BSD_DEFINE_NEXUS_DEVICE(musbotg,0 , > RTEMS_ARRAY_SIZE(musbotg_res), _res[0]);). > Sounds good. Did you put these changes on some working branch in your github repository so it would be possible to have a look? > > > Now uhub usbus and musbotg can mount on nexus bus. > OK. Sounds good. I expect you have verified that by some console output? > the issue is: it can not find the new device(such as U disk) > Which application did you use to test this. Do you have some kind of debugger so you could check whether the code reaches the umass_probe function? > So i compare with the FreeBSD boot log info, and the only difference is > FreeBSD enable the USB_HAVE_UGEN, so i guess if it is necessary > > to enable the macro USB_HAVE_UGEN. > As far as I can tell neither the am335x_musb nor the umass driver does something different based on this macro. And till now, the macro hasn't been necessary for supporting mass storage devices. It is possible that something changed and that this specific host needs USB_HAVE_UGEN for some reason to support any device but I would think it is rather unlikely. @Kevin Kirspel: It seems that you need UGEN for keyboards. Does a USB mass storage work on your target without UGEN? This might could give a hint whether the dependency is device-specific or host-specific. I'm currently not sure if any other USB device (like a hub) produces any messages on the console. But it might would be worth a try. If you have upgraded to the last libbsd, you could also try some USB-wifi-dongles. I tested with a rtl8192 based one and that did put some messages on the console. For this wifi dongle You would have to add the following drivers in nexus-devices.h: SYSINIT_MODULE_REFERENCE(wlan_ratectl_none); SYSINIT_MODULE_REFERENCE(wlan_sta); SYSINIT_MODULE_REFERENCE(wlan_amrr); SYSINIT_DRIVER_REFERENCE(rtwn_usb, uhub); SYSINIT_REFERENCE(rtwn_rtl8192cfwT); Kind regards Christian > > > Thank you for your suggestions. > > > > Best regards > > Sichen Zhao > -- embedded brains GmbH Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: GSOC 2017 RTEMS-libbsd issue
I have recently posted patches for TTY and USB serial support for FREEBSD. I was going to take a stab at supporting UGEN as well. The USB mouse and keyboard drivers need it as well. The TTY patches contain some support needed for UGEN but there is more required. Let me take a look at it today to see how much more effort it would take to get the baseline UGEN compiling (in usb_dev.c). Kevin Kirspel Electrical Engineer - Sr. Staff Idexx Roswell 235 Hembree Park Drive Roswell GA 30076 Tel: (770)-510- ext. 81642 Direct: (770)-688-1642 Fax: (770)-510-4445 From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sichen Zhao Sent: Wednesday, April 19, 2017 7:06 AM To: Christian Mauderer <christian.maude...@embedded-brains.de>; RTEMS <devel@rtems.org> Subject: Re: GSOC 2017 RTEMS-libbsd issue Hi Christian Mauderer, Hi all, I understand what you mean, i will update my RTEMS-libbsd to the newest branch. I already pull over the host controller driver files（am335x_musb.c am335x_usbss.c umass.c）from freebsd and make them compilable in rtems-libbsd. The umass.c is driver for storage device. And i already add the host controller and driver to nexus-devices.h(RTEMS_BSD_DEFINE_NEXUS_DEVICE(musbotg,0 , RTEMS_ARRAY_SIZE(musbotg_res), _res[0]);). Now uhub usbus and musbotg can mount on nexus bus. the issue is: it can not find the new device(such as U disk) So i compare with the FreeBSD boot log info, and the only difference is FreeBSD enable the USB_HAVE_UGEN, so i guess if it is necessary to enable the macro USB_HAVE_UGEN. Thank you for your suggestions. Best regards Sichen Zhao From: Christian Mauderer <christian.maude...@embedded-brains.de<mailto:christian.maude...@embedded-brains.de>> Sent: Wednesday, April 19, 2017 2:02 PM To: Sichen Zhao; RTEMS Subject: Re: GSOC 2017 RTEMS-libbsd issue Am 19.04.2017 um 07:45 schrieb Christian Mauderer: > Am 18.04.2017 um 17:10 schrieb Sichen Zhao: >> >> Hi all, >> >> I am working on my goal of GSOC 2017 project: Beaglebone black bsp >> improvement. >> >> >> And i have some issue about the RTEMS-libbsd: >> >> if i switch on the macro USB_HAVE_UGEN in the >> /rtemsbsd/include/rtems/bsd/local/opt_usb.h, >> >> There are lots of errors when compile code. >> >> >> >> >> So the macro USB_HAVE_UGEN should keep unable? I see the FreeBSD on BBB >> enable the USB_HAVE_UGEN. >> >> >> Thanks >> >> Sichen Zhao >> >> >> >> ___ >> devel mailing list >> devel@rtems.org<mailto:devel@rtems.org> >> http://lists.rtems.org/mailman/listinfo/devel<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel=DwMGaQ=2do6VJGs3LvEOe4OFFM1bA=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74=fBosmEYCuSEO6a7cKLNINnD7xmpULdLTtLnjuyse-Fk=1pIVlv0zFLnMyU1n6F32PFn3oCKUf1wH1MY-6g5kHsE=> >> > > Hello Sichen, > > I only read the introduction of the man page (see [1]) but as far as I > can tell, ugen is a generic USB driver in FreeBSD. I think it would be > useful if you want to get some generic device Information similar to the > ones you can get with lsusb in linux. From the look of it, I would > expect that you also would need it for a library like libusb (which is > used for example in OpenOCD to get a direct access to the hardware > without any special drivers). > > Normally you should not need it if there is a special driver for your > USB device in the kernel. For example, if you want to attach a USB mass > storage stick, you won't need it. > > Basically for porting the BBB USB support to libbsd, I would expect that > you have to pull over the host controller driver files from freebsd and > make them compilable in rtems-libbsd. Then you would have to add the > host controller and device drivers to nexus-devices.h. After that, it's > quite possible that you can already use some of the examples like > testsuite/media01. If you need any help or details on that process, feel > free to ask. > > Kind regards > > Christian Mauderer > > > [1] > https://www.freebsd.org/cgi/man.cgi?query=ugen=FreeBSD+11.0-RELEASE+and+Ports<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.freebsd.org_cgi_man.cgi-3Fquery-3Dugen-26manpath-3DFreeBSD-2B11.0-2DRELEASE-2Band-2BPorts=DwMGaQ=2do6VJGs3LvEOe4OFFM1bA=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74=fBosmEYCuSEO6a7cKLNINnD7xmpULdLTtLnjuyse-Fk=goBcp4AwRgGY3uAfm2qr2XOn45-x0NzWfk0JTjj1Gic=> > By the way: I noted that the libbsd in your github repo is from December 2016. There have been quite some changes since then including a mayor update to the FreeBSD head of 2016-08-23 and two smaller ones to more recent FreeBSD head versions.
Re: GSOC 2017 RTEMS-libbsd issue
Am 19.04.2017 um 07:45 schrieb Christian Mauderer: > Am 18.04.2017 um 17:10 schrieb Sichen Zhao: >> >> Hi all, >> >> I am working on my goal of GSOC 2017 project: Beaglebone black bsp >> improvement. >> >> >> And i have some issue about the RTEMS-libbsd: >> >> if i switch on the macro USB_HAVE_UGEN in the >> /rtemsbsd/include/rtems/bsd/local/opt_usb.h, >> >> There are lots of errors when compile code. >> >> >> >> >> So the macro USB_HAVE_UGEN should keep unable? I see the FreeBSD on BBB >> enable the USB_HAVE_UGEN. >> >> >> Thanks >> >> Sichen Zhao >> >> >> >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel >> > > Hello Sichen, > > I only read the introduction of the man page (see [1]) but as far as I > can tell, ugen is a generic USB driver in FreeBSD. I think it would be > useful if you want to get some generic device Information similar to the > ones you can get with lsusb in linux. From the look of it, I would > expect that you also would need it for a library like libusb (which is > used for example in OpenOCD to get a direct access to the hardware > without any special drivers). > > Normally you should not need it if there is a special driver for your > USB device in the kernel. For example, if you want to attach a USB mass > storage stick, you won't need it. > > Basically for porting the BBB USB support to libbsd, I would expect that > you have to pull over the host controller driver files from freebsd and > make them compilable in rtems-libbsd. Then you would have to add the > host controller and device drivers to nexus-devices.h. After that, it's > quite possible that you can already use some of the examples like > testsuite/media01. If you need any help or details on that process, feel > free to ask. > > Kind regards > > Christian Mauderer > > > [1] > https://www.freebsd.org/cgi/man.cgi?query=ugen=FreeBSD+11.0-RELEASE+and+Ports > By the way: I noted that the libbsd in your github repo is from December 2016. There have been quite some changes since then including a mayor update to the FreeBSD head of 2016-08-23 and two smaller ones to more recent FreeBSD head versions. Also the WLAN support has been added since then. You might should consider an update if you still work with this version. -- embedded brains GmbH Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2017 RTEMS-libbsd issue
Am 18.04.2017 um 17:10 schrieb Sichen Zhao: > > Hi all, > > I am working on my goal of GSOC 2017 project: Beaglebone black bsp > improvement. > > > And i have some issue about the RTEMS-libbsd: > > if i switch on the macro USB_HAVE_UGEN in the > /rtemsbsd/include/rtems/bsd/local/opt_usb.h, > > There are lots of errors when compile code. > > > > > So the macro USB_HAVE_UGEN should keep unable? I see the FreeBSD on BBB > enable the USB_HAVE_UGEN. > > > Thanks > > Sichen Zhao > > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > Hello Sichen, I only read the introduction of the man page (see [1]) but as far as I can tell, ugen is a generic USB driver in FreeBSD. I think it would be useful if you want to get some generic device Information similar to the ones you can get with lsusb in linux. From the look of it, I would expect that you also would need it for a library like libusb (which is used for example in OpenOCD to get a direct access to the hardware without any special drivers). Normally you should not need it if there is a special driver for your USB device in the kernel. For example, if you want to attach a USB mass storage stick, you won't need it. Basically for porting the BBB USB support to libbsd, I would expect that you have to pull over the host controller driver files from freebsd and make them compilable in rtems-libbsd. Then you would have to add the host controller and device drivers to nexus-devices.h. After that, it's quite possible that you can already use some of the examples like testsuite/media01. If you need any help or details on that process, feel free to ask. Kind regards Christian Mauderer [1] https://www.freebsd.org/cgi/man.cgi?query=ugen=FreeBSD+11.0-RELEASE+and+Ports -- embedded brains GmbH Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
GSOC 2017 RTEMS-libbsd issue
Hi all, I am working on my goal of GSOC 2017 project: Beaglebone black bsp improvement. And i have some issue about the RTEMS-libbsd: if i switch on the macro USB_HAVE_UGEN in the /rtemsbsd/include/rtems/bsd/local/opt_usb.h, There are lots of errors when compile code. [cid:effcc62c-d373-428f-9066-723c5cb9703c] So the macro USB_HAVE_UGEN should keep unable? I see the FreeBSD on BBB enable the USB_HAVE_UGEN. Thanks Sichen Zhao ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
