Stefano, Jeroen,
On Wed, 10 Jul 2013 18:04:04 +0200 Jeroen Hofstee <jer...@myspectrum.nl> wrote: > Hello Stefano / Tapani, > > On 07/10/2013 04:27 PM, Stefano Babic wrote: > > On 09/07/2013 21:46, Jeroen Hofstee wrote: > >> I cannot find any document mentioning gpio_25 though. > >> Any reason for this usage? > > That is right. There is no written documentation by Technexion about > > this pin. I have added in CC Tapani, maybe he can tell us something more. > > The GPIO is used internally on the TAM3517 SOM, and we have no > > schematics about it. We have to guess about its usage. > > Yes, and some clarification of the pin 35 would be > appreciated as well, since it is marked as ball X, I guess > it is controlled by hardware and the hub cannot be reset > from software, but that is just guessing... > > > The reason to have it is that the sources for the kernel provided by > > Technexion (an ancient 2.6.32 Version) set this pin to reset the EHCI. > > As I said, there is no further documentation and rather we can only make > > some supposition. The usage in U-Boot then reflects the usage made by > > Technexion. > > > > Fyi my linux copy (3.7) with this gpio set as the phy_reset is also > unable to properly reset it and times out. The usb is working > though, also without a proper reset.. > > >> p.s. > >> I found by sheer accidence that the usb is behaving > >> completely normal (after the patch) on rev B1. It is > >> broken on rev B without the patch and working buggy > >> with it. On rev B1 + patch the USB to SATA converter > >> is discovered as well, which I have never seen before. > >> > > I can confirm issues with version B of the TAM3517-SOM. I am testing a > > B1 SOM with a B twister. I do not know the details about changelog > > between B and B1 version of the SOM, but I got both USB and Ethernet > > problems with TAM3517-B. The same image runs without the same problems > > on a B1. > > ok, good to know. > > > There is also this pending patch by Michael: > > > > http://patchwork.ozlabs.org/patch/250290/ > > > > It is applied to u-boot-ti, not yet to mainline. > > > > on top of usb master this patch leads to: > USB0: ULPI: ulpi_reset: failed writing reset bit > ULPI: ulpi_reset: failed writing reset bit > > It does always find the stick though and never the SATA converter. > > without the gpio_25 reset, the second error goes away and > the SATA is back. > > > > > @@ -92,9 +92,6 @@ int board_init(void) > > enable_gpmc_cs_config(gpmc_XR16L2751, &gpmc_cfg->cs[3], > > XR16L2751_UART2_BASE, GPMC_SIZE_16M); > > > > - gpio_request(CONFIG_OMAP_EHCI_PHY1_RESET_GPIO, "USB_PHY1_RESET"); > > - gpio_direction_output(CONFIG_OMAP_EHCI_PHY1_RESET_GPIO, 1); > > - > > See my concerns above. Do not reset the hub in the kernel ? > > I don't get the last part, but feedback from Technexion is > needed first to remove all the guess, maybe etc. If it has a > valid function, not setting it's value might not be such a > good idea... > GPIO_25 is indeed USB PHY reset. (Pull low to reset). regards, //Tapani _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
