[PATCH v2 1/4] cmd: bind: Add unbind command with driver filter

Marek Vasut marex at denx.de
Sun Jul 23 23:45:55 CEST 2023

On 7/23/23 19:49, Miquel Raynal wrote:
> Hi Marek,


> marex at denx.de wrote on Mon, 17 Jul 2023 13:21:34 +0200:
>> Extend the driver core to perform lookup by both OF node and driver
>> bound to the node. Use this to look up specific device instances to
>> unbind from nodes in the unbind command. One example where this is
>> needed is USB peripheral controller, which may have multiple gadget
>> drivers bound to it. The unbind command has to select that specific
>> gadget driver instance to unbind from the controller, not unbind the
>> controller driver itself from the controller.
>> USB ethernet gadget usage looks as follows with this change. Notice
>> the extra 'usb_ether' addition in the 'unbind' command at the end.
>> "
>> bind /soc/usb-otg at 49000000 usb_ether
> I don't really get why this is needed? Yes, having proper bind and
> unbind methods and having them called internally is relevant, but when
> you have a single OTG controller, why is this needed?

Because you do need to bind the usb_ether driver to a controller.

I suspect you are trying to point in the direction of usb_ether_init() , 
right ? That is bogus and should be removed, because that is hard-coding 
one specific (ethernet) function to an OTG controller.

> It basically
> breaks the CLI

Can you elaborate on this ?

How does calling a 'bind' command breaks CLI ?

> , making bisects more painful and all updates just fail.

This is just utter nonsense, sorry.

>> setenv ethact usb_ether
>> setenv loadaddr 0xc2000000
>> setenv ipaddr
>> setenv serverip
>> setenv netmask
>> tftpboot 0xc2000000
>> unbind /soc/usb-otg at 49000000 usb_ether
>> "
>> Signed-off-by: Marek Vasut <marex at denx.de>
>> ---
>> Cc: Kevin Hilman <khilman at baylibre.com>
>> Cc: Lukasz Majewski <lukma at denx.de>
>> Cc: Marek Vasut <marex at denx.de>
>> Cc: Simon Glass <sjg at chromium.org>
> I've tested the whole series, unfortunately is does not work on
> AM335x/BBBW:
> * Any recovery attempted using the network will now fail in
>    the SPL, where, AFAIK, there is no way to manually bind:
> U-Boot SPL 2023.07-00806-gac80e6de9cf (Jul 23 2023 - 19:45:51 +0200)
> Trying to boot from USB eth
> Could not get PHY for eth_cpsw: addr 0
> eth0: eth_cpswusing musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
> MAC de:ad:be:ef:00:01
> HOST MAC de:ad:be:ef:00:00
> RNDIS ready
> , eth1: usb_ether

It seems the RNDIS adapter is actually ready based on the above ^ ?

> * The bind command was not available on my default configuration,
>    making it even difficult for people unaware that this command is
>    now required to fix their common commands.

It has been required ever since, it's just that many ignored the need to 
move over to DM and depended on board-specific hackage to set up their 
USB ethernet. Now that hackage broke, time to switch to the proper way.

> * Any command that expects the usb_ether driver will now fail badly
>    even after the bind call:
> => bind /ocp/usb at 47400000/usb at 47401000 usb_ether
> => fastboot usb 0
> couldn't find an available UDC

You already have the ethernet function bound to the UDC and now you are 
trying to bind another function, fastboot, right ? This is likely the 
problem. Unbind the ethernet first, then use fastboot.

> g_dnl_register: failed!, error: -19
> exit not allowed from main input shell.
> => tftp 0x81000000 zImage
> dev_get_priv: null device
> data abort
> pc : [<9ffa04ba>]          lr : [<9ff86d5f>]
> reloc pc : [<8083b4ba>]    lr : [<80821d5f>]
> sp : 9df2f920  ip : 00000000     fp : 00000003
> r10: 9df4cf48  r9 : 9df44ea0     r8 : 9ffec33c
> r7 : 00004a53  r6 : 00000000     r5 : 00000bb8  r4 : 9df4d3c0
> r3 : 9ff97653  r2 : fff1102c     r1 : 00000000  r0 : 00000000
> Flags: nzcv  IRQs off  FIQs on  Mode SVC_32 (T)
> Code: 9ffd b508 f7e6 fc4b (6801) 2000
> Resetting CPU ...
> Is there anything I missed?

Please see above.

More information about the U-Boot mailing list