[U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux

Benoît Thébaudeau benoit at wsystem.com
Thu Jan 25 10:02:35 UTC 2018


Hi Michael,

On 25/01/2018 at 06:47, Michael Nazzareno Trimarchi wrote:
> On 25 Jan. 2018 12:07 am, "Fabio Estevam" <festevam at gmail.com <mailto:festevam at gmail.com>> wrote:
> 
>     Hi Michael,
> 
>     On Wed, Jan 24, 2018 at 3:46 PM, Michael Nazzareno Trimarchi
>     <michael at amarulasolutions.com <mailto:michael at 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


More information about the U-Boot mailing list