Hi
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.)
- 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?
- 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.
- 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.]
- 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.
- 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