<div dir="ltr">Hi<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 15, 2017 at 1:26 AM, Haleigh Novak <span dir="ltr"><<a href="mailto:haleigh@edt.com" target="_blank">haleigh@edt.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">​Hello All, <br>
<br>
I am trying to connect a BBB (setup properly for ehci debugging) to a machine that was designed here at my work [well call it '(Cust)' for simplicity] I also have the running 'model' machine [lets call this one '(Orig)'] that the custom one was designed to mimic. I'm hoping that through this email I will reach enough people who have used the BeagleBone Black [BBB] to answer these questions based on the information below the questions. (Forgive me if the question is badly worded, its complicated to explain without visuals - let me know if you need a better explanation.)<br>
<br>
0) Is there a way to tell 100% for certain (a query or status of some sort) which device is considered the Master/Host and which device is considered the Slave/Peripheral in a usb connection between two fully functional stand alone machines?<br>
<br>
1) For proper use does the BBB have to be classified as the Master/Host in the usb connection?<br></blockquote><div><br></div><div>BBB is always USB device endpoint for EHCI debugging.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2) For proper use does the BBB require the connected machine (the one that ehci debugging info is desired from) to be a Master/Host, or a Slave/Peripheral device, or does it not matter; to allow successful ehci debugging?<br>
<br></blockquote><div><br></div><div>Your (Orig) or (Cust) is USB host.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[The above questions I have been Goggling, I have not found a strait forward, verified/well explained answer.]<br>
<br>
3) The conversion cord I am using I strongly suspect is an OTG, and therefore as it is connected, defines the (Cust) to be the Master/Host - would this cause a 'fight' for Master/Host status that the BBB looses and is as a result classified as a Peripheral/Slave device and rendered non-functional for my needs? [p.s - I know this conversion cord works because I can plug it into (Cust) and on the other end have a peripheral (usb flash, mouse, keyboard - all tested) plugged in and utilize the peripheral without any issue.]<br>
<br></blockquote><br>Sounds correct. <br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
4) If (1) is yes, (2) is doesn't matter or slave/peripheral; is there a way to force the usb to reclassify? Say force (Cust) to be a Slave/Peripheral device and the BBB to be the Master/Host?<br>
<br>
The BBB connects to an ehci capable port (for ehci debugging) via a MINI B connector in the BBB and a full sized usb to connect to the debug machine. Now (Orig) has full sized usb ports to which I can connect the BBB directly to and I successfully get the echi debugging information. However (Cust) only has MICRO B connectors - so I have to use a conversion cable on the end of the BBB cable to get the proper size. </blockquote><div><br>So in the Orig->Cust development you simply replaced USB A female connectors with micro-B? I'd like to review the schematic changes around that area. You should have added a conditional V+ disconnect there for hardware protection?<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The ports on the respective 'debug' machines are verified ehci capable ports, both machines have coreboot - exactly the same except for the VGA Device IDs. However (Cust) will not recognize the BBB properly, and sets it up as an ohci device - rendering the BBB virtually useless. Below is the dmesg on both machines of removing and re-inserting the BBB debug cable from the equivalent port.<br>
<br>
# DMESG addition on (Orig) after removing and re-inserting the BBB usb into the same port<br>
usb 1-3: USB disconnect, device number 2<br>
usb 1-3: new high speed USB device number 3 using ehci_hcd<br>
usb 1-3: unable to read config index 0 descriptor/start: -32<br>
usb 1-3: chopping to 0 config(s)<br>
usb 1-3: New USB device found, idVendor=0525, idProduct=c0de<br>
usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0<br>
usb 1-3: no configuration chosen from 0 choices<br></blockquote><div><br></div><div>Did (Orig) have USBDEBUG=y in its coreboot for the boot above?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
# DMESG addition on (Cust) after removing and re-inserting the BBB usb into the same port<br>
usb 4-1: USB disconnect, device number 2<br>
usb 1-1: new high speed USB device number 6 using ehci_hcd<br>
usb 1-1: device descriptor read/64, error -71<br>
usb 1-1: device descriptor read/64, error -71<br>
usb 1-1: new high speed USB device number 7 using ehci_hcd<br>
usb 1-1: device descriptor read/64, error -71<br>
usb 1-1: device descriptor read/64, error -71<br>
usb 1-1: new high speed USB device number 8 using ehci_hcd<br>
usb 1-1: device not accepting address 8, error -71<br>
usb 1-1: new high speed USB device number 9 using ehci_hcd<br>
usb 1-1: device not accepting address 9, error -71<br>
hub 1-0:1.0: unable to enumerate USB device on port 1<br>
usb 4-1: new full speed USB device number 3 using ohci_hcd<br>
usb 4-1: unable to read config index 0 descriptor/start: -32<br>
usb 4-1: chopping to 0 config(s)<br>
usb 4-1: New USB device found, idVendor=0525, idProduct=c0de<br>
usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0<br>
usb 4-1: no configuration chosen from 0 choices<br>
<br>
 Thank you for taking the time to read this. If anyone has any other suggestions as to what might be causing my issue I welcome any thoughts :).<br></blockquote><div><br></div><div>AMD's and Intels behave somewhat differently for EHCI debugging. From what I remember, for both cases the physical USB port coreboot has reserved for debugging will not be available to kernel via ehci_hcd later on. So those dmesg errors would be "normal" and something you can ignore.<br><br>Set DEBUG_USBDEBUG=y in coreboot menuconfig (Debugging -> verbose EHCI). If you are able to boot (Cust) to OS, collect coreboot console (cbmem -c) and dmesg. Send those together with the complete .config file used to build the image for us to review.<br><br>What you have done so far all sounds correct, I think it should have worked.<br><br></div><div>Kyösti<br></div><div><br></div></div></div></div></div></div>