On 8/4/23 21:37, Miquel Raynal wrote:
Describe the current situation wrt the handling of USB devices on AM33xx based boards, taking the example of a common board (the Beagle Bone Black) and explaining how the different USB gadgets can be used.
Signed-off-by: Miquel Raynal miquel.raynal@bootlin.com
I've tried to be as transparent and honnest as I could with my limited knowledge of the situation and the USB world, based on our latest dicussions. I am fully open to suggestions, changes, rephrasing...
doc/board/ti/am335x_evm.rst | 61 +++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+)
diff --git a/doc/board/ti/am335x_evm.rst b/doc/board/ti/am335x_evm.rst index ee4faec37c2..0587b506ee2 100644 --- a/doc/board/ti/am335x_evm.rst +++ b/doc/board/ti/am335x_evm.rst @@ -201,3 +201,64 @@ booting and mtdparts have been configured correctly for the board: U-Boot # spl export fdt ${loadaddr} - ${fdtaddr} U-Boot # nand erase.part u-boot-spl-os U-Boot # nand write ${fdtaddr} u-boot-spl-os
+USB device +----------
+The platform code for am33xx based designs is legacy in the sense that +it is not fully compliant with the device model in its management of the
Thanks for extending the documentation. Please, have a look at the suggestions below.
%s/device model/driver model/
+various resources. This is particularly true for the USB Ethernet gadget +which will automatically be bound to the first USB Device Controller +(UDC). This make the USB Ethernet gadget work out of the box on common +boards like the Beagle Bone Blacks and by default will prevents other +gadgets to be used.
+The output of the 'dm tree' command should be rather explicit in that
%s/should be rather explicit in that sense, showing exactly what driver is bound to what/shows which driver is bound to which/
+sense, showing exactly what driver is bound to what device, so the user +can easily configure its platform differently from the command line:
%s/its/their/ ("they" is used as gender neutral pronoun.)
+.. code-block:: text
- => dm tree
Class Index Probed Driver Name
- [...]
- misc 0 [ + ] ti-musb-wrapper | |-- usb@47400000
- usb 0 [ + ] ti-musb-peripheral | | |-- usb@47401000
- ethernet 1 [ + ] usb_ether | | | `-- usb_ether
- bootdev 3 [ ] eth_bootdev | | | `-- usb_ether.bootdev
- usb 0 [ ] ti-musb-host | | `-- usb@47401800
+Typically here any network command performed using the usb_ether +interface would work, while using other gadgets would fail:
+.. code-block:: text
- => fastboot usb 0
- All UDC in use (1 available), use the unbind command
- g_dnl_register: failed!, error: -19
- exit not allowed from main input shell.
+As hinted by the primary error message, the only controller available +(usb@47401000) is currently bound to the usb_ether driver, which makes +it impossible to the fastboot command to bind with this device (at least
%s/to/for/
+from a Bootloader point of view). The solution here would be to use the
%s/Bootloader/bootloader/
+unbind command using the class and index parameters (as shown above in
%/using/specifying/ (just to avoiding duplicate verb 'use')
+the 'dm tree' output) to target the driver to unbind:
+.. code-block:: text
- => unbind ethernet 1
+Checking the output of the 'dm tree' command now shows full availability
%s/Checking the/The/
+for the fastboot gadget to bind with UDC 0:
Could the following catch it?
"now shows the availability of the fastboot gadget as child of the first USB device controller."
Best regards
Heinrich
+.. code-block:: text
- => dm tree
Class Index Probed Driver Name
- [...]
- misc 0 [ + ] ti-musb-wrapper | |-- usb@47400000
- usb 0 [ ] ti-musb-peripheral | | |-- usb@47401000
- usb 0 [ ] ti-musb-host | | `-- usb@47401800