On 8/2/23 09:48, Miquel Raynal wrote:
Hi Marek,
ma...@denx.de wrote on Wed, 2 Aug 2023 01:07:46 +0200:
On 8/1/23 20:53, Miquel Raynal wrote:
Hi Marek,
ma...@denx.de wrote on Mon, 31 Jul 2023 16:40:04 +0200:
On 7/31/23 16:25, Miquel Raynal wrote:
Hi Marek,
ma...@denx.de wrote on Mon, 31 Jul 2023 16:08:19 +0200:
>>>> On 7/31/23 15:58, Miquel Raynal wrote:
Hi Marek,
ma...@denx.de wrote on Mon, 31 Jul 2023 15:50:58 +0200:
>>>> On 7/31/23 15:36, Miquel Raynal wrote:
Hi Marek,
ma...@denx.de wrote on Mon, 31 Jul 2023 13:44:25 +0200:
>>>> On 7/31/23 11:31, Miquel Raynal wrote:
Hi Marek,
ma...@denx.de wrote on Sat, 29 Jul 2023 16:57:09 +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@49000000 usb_ether
setenv ethact usb_ether
setenv loadaddr 0xc2000000
setenv ipaddr 10.0.0.2
setenv serverip 10.0.0.1
setenv netmask 255.255.255.0
tftpboot 0xc2000000 10.0.0.1:test.file
unbind /soc/usb-otg@49000000 usb_ether
"
Signed-off-by: Marek Vasut <ma...@denx.de>
---
I am no longer getting wrong pointer dereferences, the SPL is working in
recovery mode, TFTP "File not found" errors are no longer a problem and
I did not experience any reset while tftp'ing regular files.
One last remaining request on my side is the need for using fastboot as
well which does no longer work as-is:
>>> => fastboot usb 0
couldn't find an available UDC
g_dnl_register: failed!, error: -19
exit not allowed from main input shell.
Can you advise what bind/unbind command would be necessary here?
Either 'unbind usb_ether' or run 'dm tree' -> look up the path to usb_ether in the
tree (it will be hanging under usb_peripheral or some such), and then use 'unbind
<that path>'.
Nice `dm tree` command, never used it before.
Even when I unbind usb_ether I still get the same error:
>>> => unbind /ocp/usb@47400000/usb@47401000
=> fastboot usb 0
couldn't find an available UDC
g_dnl_register: failed!, error: -19
exit not allowed from main input shell.
Is there a specific gadget driver which I should bind again manually?
Can you share the output of dm tree before/after unbind ?
fastboot should auto-bind to the right thing.
Ok. Apparently it does not, but I don't have any clue why. If you want
me to check something else I will. Here is the output:
U-Boot 2023.07-00806-g979e7443428 (Jul 31 2023 - 11:17:06 +0200)
[...]
>>>>> watchdog 0 [ + ] omap3_wdt | |-- wdt@44e35000
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
ethernet 0 [ + ] eth_cpsw | |-- ethernet@4a100000
bootdev 2 [ ] eth_bootdev | | `--
ethernet@4a100000.bootdev
simple_bus 67 [ ] ti_sysc | |--
target-module@53100000
simple_bus 68 [ ] ti_sysc | |--
target-module@53500000
simple_bus 69 [ ] ti_sysc | `--
target-module@56000000
clk 62 [ ] fixed_clock |-- clk_mcasp0_fixed
bootstd 0 [ ] bootstd_drv |-- bootstd
bootmeth 0 [ ] bootmeth_efi | |-- efi
bootmeth 1 [ ] bootmeth_extlinux | |-- extlinux
bootmeth 2 [ ] bootmeth_pxe | |-- pxe
bootmeth 3 [ ] vbe_simple | `-- vbe_simple
timer 0 [ + ] omap_timer `-- timer@0
=> unbind /ocp/usb@47400000/usb@47401000
The commit message of this patch contains the following example:
unbind /soc/usb-otg@49000000 usb_ether
so in your case, try
unbind /ocp/usb@47400000/usb@47401000 usb_ether
Does not work, unfortunately:
=> unbind /ocp/usb@47400000/usb@47401000 usb_ether
Cannot find a device with path /ocp/usb@47400000/usb@47401000
=> unbind /ocp/usb@47400000/usb@47401000
Did this even work before , i.e. without this series, if you were to use USB
ethernet first and then fastboot second (that sequence is important) ?
Yes it did.
Can you debug this ? Basically the problem that happens is that if you run:
unbind /ocp/usb@47400000/usb@47401000
this unbind ti-musb-peripheral usb@47401000 instead of just unbinding
usb_ether usb_ether
True.
Maybe just try
unbind usb_ether
=> unbind usb_ether
unbind - Unbind a device from a driver
Usage:
unbind <node path> [<driver>]
unbind <class> <index>
unbind <class> <index> <driver>
or
unbind usb_ether usb_ether
=> unbind usb_ether usb_ether
usb_ether is not a valid uclass
ti-musb-peripheral usb@47401000 has to stay in the dm tree output after the
unbind. Or maybe try
bind /ocp/usb@47400000/usb@47401000 ti-musb-peripheral
Indeed when we perform the unbind, ti-musb-peripheral is removed. Yes,
binding it again like you advise makes it come back.
and then the fastboot thing
Unfortunately after binding it again, so with the following dm tree
snippet:
misc 0 [ + ] ti-musb-wrapper | |-- usb@47400000
usb 0 [ ] ti-musb-host | | |-- usb@47401800
usb 0 [ ] ti-musb-peripheral | | `-- usb@47401000
It still fails:
=> fastboot usb 0
couldn't find an available UDC
g_dnl_register: failed!, error: -19
exit not allowed from main input shell.
Without this series, this works:
=> unbind /ocp/usb@47400000/usb@47401000
=> bind /ocp/usb@47400000/usb@47401000 ti-musb-peripheral
=> fastboot usb 0
OK, so fastboot did not work even without this series without obscure
workarounds ?
I'm happy you call the unbind/bind sequence an "obscure workaround" ;-)
The command "fastboot usb 0" works without your series, before tftp
or after tftp, it does not matter, it used to work. Applying this
series makes it always fail.
I was just reporting that, before your series, calling unbind would
also remove ti-musb-peripheral, but calling bind again with the above
line makes the usb_ether gadget and fastboot work again. Whereas with
your series the unbind behaves identically but the bind command does not
"fix" fastboot (tftp works fine in v3).
Can you try and debug this ?
The breakage is not part of the existing code base, it was introduced
by the series. Maybe you can try with any other board with USB
peripheral and see if the behavior is identical?
Does 'fastboot usb 1' work with this series by any chance ?
When fastboot works, starting it "blocks" the CLI. When I unbind the
peripheral driver on USB 0, the fastboot command does not block any
more and yet does not print anything, it just returns "immediately"
without any log.
When I run 'fastboot usb 1' it acts like that as well, nothing happens,
without error. It acts identically before and after this series.
Please test v4
