Hi Michael, On 25/01/2018 at 06:47, Michael Nazzareno Trimarchi wrote: > On 25 Jan. 2018 12:07 am, "Fabio Estevam" <feste...@gmail.com > <mailto:feste...@gmail.com>> wrote: > > Hi Michael, > > On Wed, Jan 24, 2018 at 3:46 PM, Michael Nazzareno Trimarchi > <mich...@amarulasolutions.com <mailto:mich...@amarulasolutions.com>> > wrote: > > > This is exactly my initial propose. Can we give a try and manage on > board level? > > The kernel should not rely on the IOMUX setting done by the bootloader. > > Do you use 0x80000000 in your dts IOMUX configuration by any chance? > > 0x80000000 means that the kernel will not do IOMUX configuration and > will use the IOMUX value that comes from the bootloader. > > > Yes but those should not be even wrong. We can not be sure if the state > machine of any logic as already corrupted. Remember that we have already this > problem with the clock in general that most of the time are already enabled > and so logic can be up. > > > It seems you can fix your USB problem by not using the IOMUX value > from the bootloader and just use the good IOMUX (without SION) > explicitly in your dts. > > Does it fix the problem? > > > I think that the way to fix in a specific case could be more then one. I will > do the best on my side but I will include to not touch iomux without any > reason. I already point out that just with few pins configured like console I > get the problem . I can check two extra gpio too. > > To be clear, my board was "working". We are talking about a product in the > field since years with one minimal USB mulfuction . Other boards can have the > same problem but just not rise in the field. If the host port is direct > connected to the pen drive without an hub the USB reset can most of the time > recover the connection.
I agree with Fabio: Linux should not rely on the pad configurations performed by U-Boot. But as you say, U-Boot should work fine itself too. Have you tested the problematic USB pen drive with U-Boot? Besides your USB issue, in order to optimize power consumption, iomux-mx25.h should not set SION by default, except for the pad functions that can in no way work without it (still to be identified/tested). For the other use cases, the board files can set SION themselves, thanks to a NEW_PAD_CTRL()-like mechanism (apparently yet to be introduced into U-Boot). The changes introduced here should not break anything for the current in-tree boards. You said that setting SION only for a UART is enough to trigger your USB issue. Of course, there is no reason to set SION by default for a UART, but I was thinking about a possible link between UART and USB, as this behavior is very strange. Which USB host port are use using with the problematic pen drive, and with which PHY (SoC-internal/external, bus)? Have you checked that this port is properly configured for this PHY and PWR/OC (on/off + polarity) in both U-Boot and Linux? For instance, if this port is configured to use OC but no OC signal is actually wired, this can probably do weird things. Best regards, Benoît _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
