From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 862A0C001DE for ; Fri, 28 Jul 2023 14:00:31 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id ADB8F86908; Fri, 28 Jul 2023 16:00:27 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="JDlqe7tq"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id ADC9A8690A; Fri, 28 Jul 2023 16:00:20 +0200 (CEST) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id AF19C86900 for ; Fri, 28 Jul 2023 16:00:07 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-ua1-x929.google.com with SMTP id a1e0cc1a2514c-79a0dd101beso715805241.3 for ; Fri, 28 Jul 2023 07:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; t=1690552806; x=1691157606; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=UmA+1kCsvmuLZFPKHLMsy0qt/nYsRmSBTB0xHK/TZyA=; b=JDlqe7tqUzRCsAqpQ7bzFFiadLti0UcrzCslkuqD81t6R1I5d4wcPjJVF+Y7kOqDr1 ojUMKjhIsdyey31qb1D4yvj+TxvZVYDIDCaQTI6fj5GOgKU9Ga0LWpKm2Dfl5yaeTJFM 9hW7qIyE/fYJ/AholXgz4dTdek44IIYwbnFlE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690552806; x=1691157606; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=UmA+1kCsvmuLZFPKHLMsy0qt/nYsRmSBTB0xHK/TZyA=; b=RsHDuytV5/eGqX/8i3KyxNJ2US6Ve9Q6+1U+Z0XsAd9lluNgkPUpnZaxZRPWzan7WT kMoDYh42W61rU987NODn2XblyjCNIWifD+me6P7hR1igWn5SX1dzZAkFAYQ67nvyLs0x 7Zo/bDXxOEX30CkbpOKsskWHVMeFr9McYZiv7gs1NKCe1E2cPucGHP5f6tVjDpHpameR X1lCC+r3YOTWPubK/2lS6jqlsB35JXYaiuyZ4aYLn1bmnpgF75kfcWDOm5AkNBuu5ovo OzTDQJIIfCx6u3I2O1T+Suv49zm9BXf2hheRFfPhgnbKl0PngfavXk+JlP3K9kJdicPX ocxQ== X-Gm-Message-State: ABy/qLYtbUuGvFYHYlQUGdWwVqTm08beYcFGuG+l1Cb+zwNQVnKsbQqj IS4Pz74Wz4CEPuNWTSuZpkUBWA== X-Google-Smtp-Source: APBJJlFepthPz5+QqB21tFxeF/zYrH6sgF8OhXn265ncToYnbtkOXx9TDxLTq04KGTxNuT0bcx2GnQ== X-Received: by 2002:a67:f4c4:0:b0:445:bd3:5b3a with SMTP id s4-20020a67f4c4000000b004450bd35b3amr1892286vsn.4.1690552806377; Fri, 28 Jul 2023 07:00:06 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b00-6400-1311-45c5-0048-870a.res6.spectrum.com. [2603:6081:7b00:6400:1311:45c5:48:870a]) by smtp.gmail.com with ESMTPSA id d4-20020a67e104000000b004435819b6f9sm547913vsl.20.2023.07.28.07.00.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Jul 2023 07:00:05 -0700 (PDT) Date: Fri, 28 Jul 2023 10:00:01 -0400 From: Tom Rini To: Miquel Raynal Cc: Marek Vasut , u-boot@lists.denx.de, Kevin Hilman , Lukasz Majewski , Simon Glass Subject: Re: [PATCH v2 1/4] cmd: bind: Add unbind command with driver filter Message-ID: <20230728140001.GV3630934@bill-the-cat> References: <20230717112137.9139-1-marex@denx.de> <20230723194955.7338144c@xps-13> <20230724181345.GI3630934@bill-the-cat> <20230728145523.2318b2bc@xps-13> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HSgAYVActfl0+pzq" Content-Disposition: inline In-Reply-To: <20230728145523.2318b2bc@xps-13> X-Clacks-Overhead: GNU Terry Pratchett X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean --HSgAYVActfl0+pzq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 28, 2023 at 02:55:23PM +0200, Miquel Raynal wrote: > Hi Tom, >=20 > trini@konsulko.com wrote on Mon, 24 Jul 2023 14:13:45 -0400: >=20 > > On Sun, Jul 23, 2023 at 07:49:55PM +0200, Miquel Raynal wrote: > > > Hi Marek, > > >=20 > > > marex@denx.de wrote on Mon, 17 Jul 2023 13:21:34 +0200: > > > =20 > > > > 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. > > > >=20 > > > > 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 =20 > > >=20 > > > 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? It basically > > > breaks the CLI, making bisects more painful and all updates just fail= =2E =20 > >=20 > > I think part of the issue here is how usb_ether didn't act like the rest > > of the gadget do, for example fastboot. >=20 > It definitely is. "before it was working, now it does not anymore". > That's the gut feeling many people get when the community breaks common > habits. If we break something like this, we must at least be very clear > on what is the new behavior. I'm not sure that in the end there will be a behavior change here, but the first step to figuring out if things do or don't automatically bind right in the end is to fix the MUSB problem (see below). Then we can worry if there's a real behavior change or not. > > > > 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 > > > > " > > > >=20 > > > > Signed-off-by: Marek Vasut > > > > --- > > > > Cc: Kevin Hilman > > > > Cc: Lukasz Majewski > > > > Cc: Marek Vasut > > > > Cc: Simon Glass =20 > > >=20 > > > I've tested the whole series, unfortunately is does not work on > > > AM335x/BBBW: > > >=20 > > > * Any recovery attempted using the network will now fail in > > > the SPL, where, AFAIK, there is no way to manually bind: > > >=20 > > > 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 =20 > >=20 > > For testing, what happens if you disable CPSW? Does it both bind (as it > > shows here) and then use the expected device? >=20 > Disabling CPSW breaks the link, I had to ensure ft_board_setup in the > am335x arch folder was still available (and returned 0). But once I > managed to start I did not observe any improvements. >=20 > U-Boot SPL 2023.07-00806-gac80e6de9cf-dirty (Jul 28 2023 - 14:49:48 +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 So it's just not working, is what we both observe, on this platform. > > > * 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. =20 > >=20 > > Yes, we'll need to make that default y if USB_ETHER. >=20 > Agreed. >=20 > > > * Any command that expects the usb_ether driver will now fail badly > > > even after the bind call: > > > =20 > > > =3D> bind /ocp/usb@47400000/usb@47401000 usb_ether > > > =3D> fastboot usb 0 =20 > > > couldn't find an available UDC > > > g_dnl_register: failed!, error: -19 > > > exit not allowed from main input shell. =20 > > > =3D> tftp 0x81000000 zImage =20 > > > dev_get_priv: null device =20 > >=20 > > Well, does it work if you do: > > bind /ocp/usb@47400000/usb@47401000 usb_ether > > tftp 0x81000000 zImage > > ? >=20 > No, I already tried both: >=20 > U-Boot SPL 2023.07-00806-gac80e6de9cf (Jul 23 2023 - 19:45:51 +0200) > Trying to boot from MMC2 >=20 >=20 > U-Boot 2023.07-00806-gac80e6de9cf (Jul 23 2023 - 19:45:51 +0200) >=20 > CPU : AM335X-GP rev 2.1 > Model: TI AM335x BeagleBone Black > DRAM: 512 MiB > Core: 160 devices, 18 uclasses, devicetree: separate > WDT: Started wdt@44e35000 with servicing every 1000ms (60s timeout) > NAND: 0 MiB > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > Loading Environment from FAT... Unable to read "uboot.env" from mmc1:1...= =20 > not set. Validating first E-fuse MAC > Net: Could not get PHY for ethernet@4a100000: addr 0 > eth2: ethernet@4a100000using 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 > , eth3: usb_ether > =3D> bind /ocp/usb@47400000/usb@47401000 usb_ether > =3D> 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 : 0000538c r6 : 00000000 r5 : 00000bb8 r4 : 9df4d3c0 > r3 : 9ff97653 r2 : fff69249 r1 : 00000000 r0 : 00000000 > Flags: nzcv IRQs off FIQs on Mode SVC_32 (T) > Code: 9ffd b508 f7e6 fc4b (6801) 2000=20 > Resetting CPU ... I had talked with Marek a bit on IRC as well and found that yes, there's some additional problem seemingly with MUSB. Perhaps you can debug what's going on here? --=20 Tom --HSgAYVActfl0+pzq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmTDyeEACgkQFHw5/5Y0 tyyfKwwAnze2dts/Lk/vEbUBDKyyvnNQnjWldok3LsT4TUlgej1JMsX7lPnnUMKZ i2fc2X/dhBSdbTkQgoQzdf9Tr88m4u/GOK0Wy+kSzdSrxywBzjgCjD6ByGdXF8k+ /KbMUhdUfb84zpRT6FHxCCDGzKwHhpxP3zjQxl97vd6HDlaE1mKMl8Z8xROo0Y9w QQKPd+naH04+tSQh2YGg8INNo6TXP4YjYmO7YXKPyHpfLBMj1WCxnu6564SrZauA UsDft2cQ873j4OBCgTuhoIZZenfcbsNeSQqkhf8Yzp4dBG8uVifVDHIob2to+2UT bbnMxzyd/T0EvQZVcizxVHhZ7jAS84Aro9p8q6Tg/s+fxMSWhqCDzNwkFmRpgD76 Of7TefLeYAcV//VeB426P3zgAFXwISBtgbUSf9Usa7SLB4d7EM6vRPMbB222NXr6 7aemNxbUHv0EO4CFOGi4EJKf8qLXFX56Mix3baDcxdmJmdgnGvMi4CKC865G6tlt OM8dmSbC =R7Lq -----END PGP SIGNATURE----- --HSgAYVActfl0+pzq--