On Sat, Apr 15, 2017 at 1:26 AM, Haleigh Novak <haleigh@edt.com> wrote:

Hello All,

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.)

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?

1) For proper use does the BBB have to be classified as the Master/Host in the usb connection?

BBB is always USB device endpoint for EHCI debugging.

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?

Your (Orig) or (Cust) is USB host.

[The above questions I have been Goggling, I have not found a strait forward, verified/well explained answer.]

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.]

Sounds correct.

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?

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.

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?

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.

# DMESG addition on (Orig) after removing and re-inserting the BBB usb into the same port
usb 1-3: USB disconnect, device number 2
usb 1-3: new high speed USB device number 3 using ehci_hcd
usb 1-3: unable to read config index 0 descriptor/start: -32
usb 1-3: chopping to 0 config(s)
usb 1-3: New USB device found, idVendor=0525, idProduct=c0de
usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-3: no configuration chosen from 0 choices

Did (Orig) have USBDEBUG=y in its coreboot for the boot above?

# DMESG addition on (Cust) after removing and re-inserting the BBB usb into the same port
usb 4-1: USB disconnect, device number 2
usb 1-1: new high speed USB device number 6 using ehci_hcd
usb 1-1: device descriptor read/64, error -71
usb 1-1: device descriptor read/64, error -71
usb 1-1: new high speed USB device number 7 using ehci_hcd
usb 1-1: device descriptor read/64, error -71
usb 1-1: device descriptor read/64, error -71
usb 1-1: new high speed USB device number 8 using ehci_hcd
usb 1-1: device not accepting address 8, error -71
usb 1-1: new high speed USB device number 9 using ehci_hcd
usb 1-1: device not accepting address 9, error -71
hub 1-0:1.0: unable to enumerate USB device on port 1
usb 4-1: new full speed USB device number 3 using ohci_hcd
usb 4-1: unable to read config index 0 descriptor/start: -32
usb 4-1: chopping to 0 config(s)
usb 4-1: New USB device found, idVendor=0525, idProduct=c0de
usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 4-1: no configuration chosen from 0 choices

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 :).

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.

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.

What you have done so far all sounds correct, I think it should have worked.

Kyösti