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