Hi Tom, Thanks for testing. One more thing needs fixing, my fault. I forgot that the mux_data.h file comes from the sEVM w/o any modification. Not only USB shall not work...
Fix is in http://patchwork.ozlabs.org/patch/244233/ Please see comments inline below. On 16/05/13 01:06, Tom Rini wrote: > On Wed, May 15, 2013 at 06:55:24PM +0300, Lubomir Popov wrote: > >> Prerequisites: appropriate patches to the USB EHCI and Eth >> drivers, and to the OMAP5 clock register definitions. >> >> Signed-off-by: Lubomir Popov <lpo...@mm-sol.com> >> --- >> Assumption is that this code shall run on TI 750-2628-21X >> hardware (also known as OMAP5432 ES2.0 PandaBoard5) - the >> GPIOs that I used used for HSIC reset correspond to that >> board. Looking at mux_data.h however, I'm somewhat concerned. >> All the uevm board files are inherited from the sEVM, which >> is a very different hardware platform, and I'm afraid that >> only changing the file names might not be sufficient. >> >> The patch is not tested yet due to lack of hardware. Tom, >> I'm hoping for your assistance. > > OK, I applied: > $ git log --oneline master.. > 93460ef OMAP4/5: Add USB EHCI support > d18c49c OMAP5: Enable USB Ethernet support with LAN9730 > 15a4481 OMAP5: Enable access to auxclk registers > f307fc2 OMAP5: Power: Add more functionality to Palmas driver > efdf00c OMAP5: uEVM: Enable USB EHCI functionality (preliminary, not tested) > And added: > +#define CONFIG_USB_ULPI > +#define CONFIG_USB_ULPI_VIEWPORT_OMAP > to include/configs/omap5_uevm.h Actually not needed at all for this board - it does not have any ULPI PHYs. We shall just get dead code. > > And usb start/usb rescan don't see any devices. > OMAP5432 uEVM # usb start > (Re)start USB... > USB0: USB EHCI 1.00 > scanning bus 0 for devices... 1 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > scanning usb for ethernet devices... 0 Ethernet Device(s) found > > Cable was plugged into the eth and a storage device was also plugged in. > I suspect that we need to set CONFIG_OMAP_EHCI_PHY1_RESET_GPIO / > CONFIG_OMAP_EHCI_PHY2_RESET_GPIO. I'm looking around for the schematic > so I can try and find that out. No. This is for ULPI PHY reset only, we are using CONFIG_OMAP_HSIC_PORT2_RESET_GPIO and CONFIG_OMAP_HSIC_PORT3_RESET_GPIO for the HSIC devices. The problem is that these pads were not configured to GPIO mode. Above patch fixes this. > Best regards, Lubo _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
