Well... it could be worse
i believe in older omap (2?) processors 480 Mbps was not supported on the
OTG...
AFAIR: OMAP2420 didn't support HS on OTG - OMAP2430 did 
Søren
Hi everyone,
Here is my first weekly report, according to the format discussed on IRC earlier.
http://beagleboard-usbsniffer.blogspot.com/2010/05/weekly-report-week-0.html
Best regards,
Nicolas
Frans,
Thanks. Actually I just managed to build Angstrom's console-image, using around 5-10 gigs I think (previously it ate more than 20 IIRC).
What I did was the following: first build task-boot, then task-base, then console-image (and do some cleanup in between).
It seems like "do_rm_work" is not called for many packages when you use these targets, leaving lots of garbage in build/tmp-angstrom_2008_1/work (sometimes more than 1 gig per package), but I could manually clean these by running bitbake <package>, as it would execute "do_rm_work" (probably simply removing build/tmp-angstrom_2008_1/work/<arch>/<package> would also have worked).
For the kernel, I build it outside the OpenEmbedded tree, it's easier that way.
Best regards,
Nicolas
Hi Nicolas
While debugging MUSB stuff for a customer we ran into some silicon bugs of the MUSB block and had the kernel team do a waorkaround for it. It turns out the workaround isn''t enabled by default. If you are experiencing trouble with some devices, add musb_hdrc.fifo_mode=5 to bootargs, that will but it in '8k' mode for the endpoint descriptors. It fixes things like webcams for me, I'm not sure how it impacts your work.
regards,
Koen
Koen,
Thanks for the hint. You are saying that it causes problems with webcams, do you have any idea if the bug hits the MUSB only in host mode, or if it's a more general problem (with the FIFOs?) that also occurs in device mode?
Best regards,
Nicolas
Koen,
Thanks for the hint. You are saying that it causes problems with webcams, do you have any idea if the bug hits the MUSB only in host mode, or if it's a more general problem (with the FIFOs?) that also occurs in device mode?
As I understand it (and I know virtually nothing about it) is that there are hardware bugs with endpoint allocation and that this mode forces it to fit N endpoints into 8k, instead of the full 16k. So anything using endpoints is affected. It is possible that you will never hit the bugs, but it is always nice to use a known working config instead of a known defective one. I'm working to make mode 5 the default so no funky bootargs are needed. But till then, musb_hdrc.fifo_mode=5 is your friend
I also heard that the xM won't be affected by this silicon bug, but I haven't followed up on that remark.
regards,
Koen
Koen,
Thanks for the hint. You are saying that it causes problems with webcams, do you have any idea if the bug hits the MUSB only in host mode, or if it's a more general problem (with the FIFOs?) that also occurs in device mode?
As I understand it (and I know virtually nothing about it) is that there are hardware bugs with endpoint allocation and that this mode forces it to fit N endpoints into 8k, instead of the full 16k. So anything using endpoints is affected. It is possible that you will never hit the bugs, but it is always nice to use a known working config instead of a known defective one. I'm working to make mode 5 the default so no funky bootargs are needed. But till then, musb_hdrc.fifo_mode=5 is your friend
I also heard that the xM won't be affected by this silicon bug, but I haven't followed up on that remark.
Understood. Thank you.
Regards,
Nicolas
Hi all,
My report for week 1:
http://beagleboard-usbsniffer.blogspot.com/2010/05/weekly-report-week-1.html
Best regards,
Nicolas
Hi all,
As discussed just before on IRC, I'm reposting this.
http://beagleboard-usbsniffer.blogspot.com/2010/06/weekly-report-week-2.html
Best regards,
Nicolas