[coreboot] BeagleBone Black [Master/Slave] Connection

[Kyösti Mälkki]

Hi

On Sat, Apr 15, 2017 at 1:26 AM, Haleigh Novak <haleigh at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170415/f8f8aa28/attachment.html>