On Fri, Dec 16, 2016 at 4:07 PM, roboknight <[email protected]> wrote: > > > On Friday, December 16, 2016 at 4:44:33 PM UTC-5, RobertCNelson wrote: >> >> On Fri, Dec 16, 2016 at 3:38 PM, roboknight <[email protected]> wrote: >> > I read through this thread and noted that the PRU isn't working yet? I >> > ended up compiling a 4.9.0-rc6 kernel, although not the ti variant, >> > and was able to get the PRU working with the old UIO driver. I was >> > hoping >> > at some point to switch to the new remoteproc driver, but >> > reading through this thread, it seems as its not ready? I know this >> > thread >> > is about a month old now, but is my understanding accurate? >> > Or have things progressed to a working state? If my understanding is >> > accurate, how much more work does the remoteproc driver require? >> >> Correct only, uio_pruss as it's mostly upstream, and with a quick hack >> we have a version that is compatible with 3.8.13 kernel's.. > > > I take it that's why my uio_pruss works in 4.9... At least I haven't had any > problems... yet.
Yeah you shouldn't have any problems, the one nice thing about uio, it let's you handle everything. ;) >> The remoteproc driver isn't upstream, TI will rebase it from v4.4.x-ti >> and port it to v4.9.x-ti when they feel like it. ;) >> >> > >> > I've even tested the old driver with my code and without any changes, it >> > was >> > performing like a champ. My only problem now is I haven't been >> > able to get the USB gadget interface to work. Everything seems to go >> > fine >> > up until I attempt: >> > >> > ls /sys/class/udc > UDC # enable my gadget >> > >> > At this point, I get a crash around line 620 in f_hid.c in >> > usb/gadget/function . At least the crash is in alloc_ep_req. It says, >> > if >> > I'm reading it right, that the in_ep is NULL, which I don't think it is >> > supposed to be or can't be. So I'm not sure what I'm doing wrong that >> > I'm >> > getting a NULL endpoint, but I thought maybe I hadn't configured the >> > kernel >> > quite right for USB. So now that TI has a more "official" 4.9 release, >> > maybe things work there? >> >> Double check with v4.9.0, i've been also messing around with the usb >> gadget configfs interface: >> >> >> https://github.com/RobertCNelson/boot-scripts/blob/master/boot/omap3_beagle.sh#L44-L90 >> >> hopefully we drop the old g_multi version that we use on the bone.. >> > > I am not sure what's going on here, but I'll check this out. Either I'm not > doing something with configfs properly, or I've screwed up the kernel > config. > I did note that when I look at my dmesg, I see musb-hdrc.1.auto showing up > as a "host" driver and musb-hdrc.0.auto showing up under /sys/class/udc. > I didn't know if the musb-hdrc.0.auto under /sys/class/udc means that its an > "available" udc, or if it is the "device" udc, or if things are screwing up > altogether. > Thanks for the script pointer. On the beagle xM, we just have one musb port, thus "musb-hdrc.0.auto".. On the BeagleBone, usb0 = peripheral usb1 = host So use "musb-hdrc.0.auto" Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYhZSQVF3_Wo4LX9XD0Fa8CGeP1qA0T5F_tbaa0x0aTEaQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
