Just a quick google search, but the "automatic reboot" portion of the second "answer" got my attention.
http://stackoverflow.com/questions/20467010/usb0-changed-the-mode-due-to-emi-using-am1808 Also for what it is worth, I've "booted" my BBB via external / self powered USB Hard drive in the past, and let it idle with the occasional tinkering of the rootfs with no problems at all. The kernel i used was 3.8.13-bone21 converted to a uImage( have not done this recently, as I find NFS root much handier). Also for what it is worth, I have always powered my beaglebone black via the Mini USB port. Which is an A5A. On Sat, Nov 22, 2014 at 4:12 PM, david turvene <[email protected]> wrote: > On Thursday, November 20, 2014 8:35:49 AM UTC-5, [email protected] > wrote: >> >> Ok, I have now got somewhere with this. What seems to be happening at >> least on our custom design (similar to BBB) is: >> >> 1. We have an oscilloscope on the USB0 VBUS line. >> 2. We have set the USB0 controller's mode to "peripheral" using the >> DTB's dr_mode setting. >> 3. When the g_ether gadget's module is loaded into the kernel the >> VBUS line begins pulsing high (about 2V) once every 2 seconds. It appears >> that the g_ether module causes the USB0 controller to ignore its >> "peripheral" status and go into "otg" mode. I think in OTG mode the USB0 >> pulses the VBUS line to check on the capacitance of the line and thus see >> if a slave devise is attached. If one is the USB controller will go into >> host mode. It can't really do this on our board as there is no ability to >> power the VBUS line. >> 4. As the USB0 VBUS line is connected to the TPS65217's USB power >> input it sees this pulsing. I guess once in a while it decides to move to >> USB power and this fails so the system reboots. >> >> If this is the case a few things at fault here I think. >> >> 1. The TPS65217 should prioritise AC power over USB power and thus >> not try to switch to USB power when AC power is present and not switch on >> mere pulses (chip bug ?) >> 2. The Linux USB stack (musb driver ?) should not allow the USB >> controller to go into OTG mode when set to "host" or "peripheral". This >> may >> be in the musb driver or g_ether module ? (Linux kernel bug ?) >> 3. The AM335x (we are using an AM3358BZCZ) CPU appears to drive the >> USB0 VBUS line (we have changed the in-series resistor to 1k and can see >> the pin driving), possibly with a current source, in order to check for >> VBUS capacitance. The AM335x manual states this line is an analogue input >> only not an output. So there is a documentation discrepancy there. >> (documentation bug ?) >> >> Fixes are (I think): >> 1. Look at the Linux kernel to try and see why it goes into OTG mode when >> the g_ether module (may be other cases as well) is loaded and stop this >> happening when the device is set to "peripheral" mode. We are using 3.12.10 >> maybe this has been fixed in later versions ? >> 2. Increase the value of the CPU's VBUS pins series resistor (maybe 10k >> ?). Not sure if this will work yet. >> > > Well, this post seem to be the definitive investigation of the problem. I > admire the persistence and follow-up documentation. > > I'm running a custom build off RCN github 3.18.0-rc3-bone1 and my system > has run as expected since I changed USB0 to "peripheral", in a variety of > stressed wifi chip configs slaved on a USB hub (e.g. one in normal mode, > another in 802.11 RFMON mode - which overwhelms the single-core CPU.) I'm > used a mix of wifi chips from Realtek and Ralink. And I'd love to > investigate the whole gadget layer more.... > > So, my question is: what impact does the behavior have when USB0 is in > "peripheral" mode? Is it a debilitating bug? I'm just not familiar enough > with USB to understand the impact. > > Dave > > -- > 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]. > For more options, visit https://groups.google.com/d/optout. > -- 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]. For more options, visit https://groups.google.com/d/optout.
