Hi On Sat, Apr 15, 2017 at 1:26 AM, Haleigh Novak <[email protected]> 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
-- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
