| Message ID | 5193AFEC.60700@mm-sol.com |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
On 18:55-20130515, Lubomir Popov wrote: > Prerequisites: appropriate patches to the USB EHCI and Eth > drivers, and to the OMAP5 clock register definitions. proper commit message is needed before this goes from RFC to patch. > > Signed-off-by: Lubomir Popov <lpopov@mm-sol.com> > --- > Assumption is that this code shall run on TI 750-2628-21X > hardware (also known as OMAP5432 ES2.0 PandaBoard5) - the uEVM - there is no PandaBoard5 in existence. https://www.svtronics.com/index.php?route=product/product&product_id=33 Just a minor nit: > const struct omap_sysinfo sysinfo = { > - "Board: OMAP5430 EVM\n" > + "Board: OMAP5432 uEVM\n" nit: does not belong to this patch.
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 <lpopov@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 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.
On 05/15/2013 05:55 PM, Lubomir Popov wrote: > Prerequisites: appropriate patches to the USB EHCI and Eth > drivers, and to the OMAP5 clock register definitions. Hi Lubomir, I have been trying to get the USB working on omap5 uEVM yesterday. In addition to your code, I added the changes necessary to pinmux the 79 and 80 GPIOS correctly, but it does not seem to work. I suspect there is something else missing than simply USB specific bits, because when the ethernet phy is supposedly out of reset, the ethernet leds keep turned off. I was thinking about checking the PMIC registers. Regards.
On 05/16/2013 12:06 AM, Tom Rini wrote: > CONFIG_OMAP_EHCI_PHY2_RESET_GPIO. I'm looking around for the schematic > so I can try and find that out. There: https://www.svtronics.com/download/OMAP5uEVM_Spec_DOC-21163_REV0_4.pdf
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 <lpopov@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
Hi Gilles, On 16/05/13 01:31, Gilles Chanteperdrix wrote: > On 05/15/2013 05:55 PM, Lubomir Popov wrote: > >> Prerequisites: appropriate patches to the USB EHCI and Eth >> drivers, and to the OMAP5 clock register definitions. > > > Hi Lubomir, > > I have been trying to get the USB working on omap5 uEVM yesterday. In > addition to your code, I added the changes necessary to pinmux the 79 > and 80 GPIOS correctly, but it does not seem to work. I suspect there is > something else missing than simply USB specific bits, because when the > ethernet phy is supposedly out of reset, the ethernet leds keep turned > off. I was thinking about checking the PMIC registers. PMIC wouldn't be related. Did you pull the current u-boot master and then apply the following patches before testing? Eager to know ;) http://patchwork.ozlabs.org/patch/232742/ http://patchwork.ozlabs.org/patch/244100/ > > Regards. > Best regards, Lubo
On Thu, May 16, 2013 at 11:23:00AM +0300, Lubomir Popov wrote: > 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/ No change. > Please see comments inline below. Ah right, thought so after reading over the SRM.
Hi Tom, On 16/05/13 15:28, Tom Rini wrote: > On Thu, May 16, 2013 at 11:23:00AM +0300, Lubomir Popov wrote: > >> 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/ > > No change. > >> Please see comments inline below. > > Ah right, thought so after reading over the SRM. > I found here a couple of old uEVMs (the old 750-2617 board type with OMAP5432 ES1.0 and the old DDR3 power scheme). One was HS, so of no use directly (no time to play with image signing). On the GP, I get the following: U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:18:35) OMAP5432 ES1.0 U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:18:35) OMAP5432 ES1.0 SDRAM: identified size not same as expected size identified: 4 expected: 40000000 OMAP SD/MMC: 0 spl: fat register err - -1 ### ERROR ### Please RESET the board ### <reset> U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:18:35) OMAP5432 ES1.0 U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:18:35) OMAP5432 ES1.0 SDRAM: identified size not same as expected size identified: 4 expected: 40000000 OMAP SD/MMC: 0 spl: fat register err - -1 ### ERROR ### Please RESET the board ### <...> The same U-Boot (yesterday's u-boot-ti/master), just configured for my SOM5_EVB board: U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) OMAP5430 ES1.0 U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) OMAP5430 ES1.0 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) CPU : OMAP5430 ES1.0 Board: MM Solutions SOM5 EVB I2C: ready DRAM: 2 GiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment In: serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 mmc0 is current device reading boot.scr 109 bytes read in 3 ms (35.2 KiB/s) Running bootscript from mmc0 ... ## Executing script at 82000000 ** File not found /boot/zImage ** SOM5_EVB # usb start (Re)start USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 6 USB Device(s) found scanning usb for storage devices... 3 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found SOM5_EVB # usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Mass Storage (480 Mb/s, 98mA) | USB Mass Storage Device 6fc59c7217b150 | +-3 Hub (480 Mb/s, 2mA) | | | +-4 Mass Storage (480 Mb/s, 96mA) | | Generic Ultra Fast Media Reader 000000264001 | | | +-5 Mass Storage (480 Mb/s, 200mA) | FSC MEMORYBIRD USB2 C157040817120315AA | +-6 Vendor specific (480 Mb/s, 500mA) SOM5_EVB # I guess something at very low level mem init does not match the 5432 ES1.0 or the DDRs. So unfortunately I can't get to U-Boot and test USB. Also please notice that the SPL now seems to be executed twice (on both boards). This was not the case until recently, at least with the mainline. Anything to do with all those relocation discussions/patches? Best regards, Lubo
On Thu, May 16, 2013 at 05:56:57PM +0300, Lubomir Popov wrote: [snip] > The same U-Boot (yesterday's u-boot-ti/master), just configured for > my SOM5_EVB board: > > U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) > OMAP5430 ES1.0 > > U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) > OMAP5430 ES1.0 > OMAP SD/MMC: 0 > reading u-boot.img > reading u-boot.img > > > U-Boot 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) [snip] > Also please notice that the SPL now seems to be executed twice (on both > boards). This was not the case until recently, at least with the mainline. > Anything to do with all those relocation discussions/patches? Can you bisect and see when something changed? It looks like it's printing the same string twice, not loading SPL loading SPL loading U-Boot, but I could be wrong..
Hi Tom, > On Thu, May 16, 2013 at 05:56:57PM +0300, Lubomir Popov wrote: > [snip] >> The same U-Boot (yesterday's u-boot-ti/master), just configured for >> my SOM5_EVB board: >> >> U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) >> OMAP5430 ES1.0 >> >> U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) >> OMAP5430 ES1.0 >> OMAP SD/MMC: 0 >> reading u-boot.img >> reading u-boot.img >> >> >> U-Boot 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) > [snip] >> Also please notice that the SPL now seems to be executed twice (on both >> boards). This was not the case until recently, at least with the >> mainline. >> Anything to do with all those relocation discussions/patches? > > Can you bisect and see when something changed? It looks like it's > printing the same string twice, not loading SPL loading SPL loading > U-Boot, but I could be wrong.. Well, if I go to work tomorrow - I think I got the flu today and am feeling really sick this evening. > > -- > Tom L. >
Hi, On Thursday 16 May 2013 08:59 PM, Tom Rini wrote: > On Thu, May 16, 2013 at 05:56:57PM +0300, Lubomir Popov wrote: > [snip] >> The same U-Boot (yesterday's u-boot-ti/master), just configured for >> my SOM5_EVB board: >> >> U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) >> OMAP5430 ES1.0 >> >> U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) >> OMAP5430 ES1.0 >> OMAP SD/MMC: 0 >> reading u-boot.img >> reading u-boot.img >> >> >> U-Boot 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) > [snip] >> Also please notice that the SPL now seems to be executed twice (on both >> boards). This was not the case until recently, at least with the mainline. >> Anything to do with all those relocation discussions/patches? > Can you bisect and see when something changed? It looks like it's > printing the same string twice, not loading SPL loading SPL loading > U-Boot, but I could be wrong.. I tried SD and EMMC boot on the latest mainline on my 5432 ES2.0 and did not see any issue. What boot are you trying ? U-Boot SPL 2013.04-00237-g9d32686 (May 17 2013 - 10:54:15) OMAP5432 ES2.0 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.04-00237-g9d32686 (May 17 2013 - 10:54:15) CPU : OMAP5432 ES2.0 Board: OMAP5430 EVM I2C: ready DRAM: 2 GiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 OMAP5430 EVM # Regards, Sricharan
> Hi, > On Thursday 16 May 2013 08:59 PM, Tom Rini wrote: >> On Thu, May 16, 2013 at 05:56:57PM +0300, Lubomir Popov wrote: >> [snip] >>> The same U-Boot (yesterday's u-boot-ti/master), just configured for >>> my SOM5_EVB board: >>> >>> U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) >>> OMAP5430 ES1.0 >>> >>> U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) >>> OMAP5430 ES1.0 >>> OMAP SD/MMC: 0 >>> reading u-boot.img >>> reading u-boot.img >>> >>> >>> U-Boot 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) >> [snip] >>> Also please notice that the SPL now seems to be executed twice (on both >>> boards). This was not the case until recently, at least with the >>> mainline. >>> Anything to do with all those relocation discussions/patches? >> Can you bisect and see when something changed? It looks like it's >> printing the same string twice, not loading SPL loading SPL loading >> U-Boot, but I could be wrong.. > I tried SD and EMMC boot on the latest mainline on my 5432 ES2.0 and > did not see any issue. What boot are you trying ? The TI tree - see above. This is where Tom applied the USB patches. Unfortunately I cannot be of any help today - I'm sick and at home. > > U-Boot SPL 2013.04-00237-g9d32686 (May 17 2013 - 10:54:15) > OMAP5432 ES2.0 > OMAP SD/MMC: 0 > reading u-boot.img > reading u-boot.img > > > U-Boot 2013.04-00237-g9d32686 (May 17 2013 - 10:54:15) > > CPU : OMAP5432 ES2.0 > Board: OMAP5430 EVM > I2C: ready > DRAM: 2 GiB > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > Using default environment > > In: serial > Out: serial > Err: serial > Hit any key to stop autoboot: 0 > OMAP5430 EVM # > > Regards, > Sricharan > Regards, Lubo
On Thu, May 16, 2013 at 09:43:27PM +0300, Lubomir Popov wrote: > Hi Tom, > > > On Thu, May 16, 2013 at 05:56:57PM +0300, Lubomir Popov wrote: > > [snip] > >> The same U-Boot (yesterday's u-boot-ti/master), just configured for > >> my SOM5_EVB board: > >> > >> U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) > >> OMAP5430 ES1.0 > >> > >> U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) > >> OMAP5430 ES1.0 > >> OMAP SD/MMC: 0 > >> reading u-boot.img > >> reading u-boot.img > >> > >> > >> U-Boot 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) > > [snip] > >> Also please notice that the SPL now seems to be executed twice (on both > >> boards). This was not the case until recently, at least with the > >> mainline. > >> Anything to do with all those relocation discussions/patches? > > > > Can you bisect and see when something changed? It looks like it's > > printing the same string twice, not loading SPL loading SPL loading > > U-Boot, but I could be wrong.. > Well, if I go to work tomorrow - I think I got the flu today and am > feeling really sick this evening. Sorry you're not feeling well. Note that I don't see it on my uEVM: U-Boot SPL 2013.04-00052-g47c6ea0 (May 17 2013 - 09:42:37) OMAP5432 ES2.0 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.04-00052-g47c6ea0 (May 17 2013 - 09:42:37) CPU : OMAP5432 ES2.0 ...
On 05/16/2013 10:39 AM, Lubomir Popov wrote: > Hi Gilles, > > On 16/05/13 01:31, Gilles Chanteperdrix wrote: >> On 05/15/2013 05:55 PM, Lubomir Popov wrote: >> >>> Prerequisites: appropriate patches to the USB EHCI and Eth >>> drivers, and to the OMAP5 clock register definitions. >> >> >> Hi Lubomir, >> >> I have been trying to get the USB working on omap5 uEVM yesterday. In >> addition to your code, I added the changes necessary to pinmux the 79 >> and 80 GPIOS correctly, but it does not seem to work. I suspect there is >> something else missing than simply USB specific bits, because when the >> ethernet phy is supposedly out of reset, the ethernet leds keep turned >> off. I was thinking about checking the PMIC registers. > PMIC wouldn't be related. Hi, My idea was that if the ethernet chip does not power up, maybe it is because some LDO or SMPS needs to be powered on. The board documentation says for some LDOs that they are enabled on boot and does not say for others, so that may be because they need to be enabled. > > Did you pull the current u-boot master and then apply the following patches > before testing? Eager to know ;) > > http://patchwork.ozlabs.org/patch/232742/ > http://patchwork.ozlabs.org/patch/244100/ I was working with u-boot-ti master, applied all the patches, and it still does not seem to work. I just tried the u-boot master branch but it fails to compile for omap5_uevm. Regards.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/18/2013 11:25 AM, Gilles Chanteperdrix wrote: > I was working with u-boot-ti master, applied all the patches, and > it still does not seem to work. I just tried the u-boot master > branch but it fails to compile for omap5_uevm. Did you have other patches applied? master works here, but there's some patches required for the USB stuff that haven't yet made it from u-boot-arm to u-boot. - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRl7VEAAoJENk4IS6UOR1WOnsP+wdR4XsY0vU+BQ39U8cyvWZA xCCGsIGwQX24xbGCs+lcdYrj9jIRJfOC+WviJgbgHh8lAfguB7/9nRmwsKgcjHa/ /XnofnJY6o3bkEqEz1ROU82IeFWw6eFW3U8xloGT9SptE8Ak7jBiYhhvKuj6AxFb w8iX6EVC9CrN2NoG7TF0Ah/ekwunvMb2mHxMGepCLVBRtIOH3G2kFSIEqB4EM+0t l0Jt2wN9NFb3gmqJ5iJ0htv/k83HShzsVpUfJJxPv92hWzhYog9l/BIWpI0SNqVH L65xSGW0r6/9A2NIzPTq0jvfUiBAWauDjYyaN9p9E+uhwJlse29LD4bUabnYFB08 F/4374IW0CgcLH6H6BDl2OdQlj6MkLu8qchsA3JzWlcy4nX/EdjHoqZA1pGkJYq0 9h4jgccHRxzDZvX8g6EEgK8TNEn2DaOFq8vZGzV2uyAEX1pMHycYAE5zLjPFFBYt GGfSoDBAr7c2VhHT77BXKE4I1hr9HCBMT8/t3thMJKsRBtn3PRZWDHNa6buvftiv 1HEkzIANQldOWeZV8LoJwj39JI1gHMcjhrXfXgaxq+uPEyX2ErMPV8MbHRyTXvDD 5jGqLDmGbU5sXXaLIdTjZyGp/RqF1dh5k7S4XzpdgTsG5INX1+WmaA+F4z8YrgFi 9ia7Juzl0WVNVaxf5WSh =XAfN -----END PGP SIGNATURE-----
On 05/18/2013 07:07 PM, Tom Rini wrote: > On 05/18/2013 11:25 AM, Gilles Chanteperdrix wrote: > >> I was working with u-boot-ti master, applied all the patches, and >> it still does not seem to work. I just tried the u-boot master >> branch but it fails to compile for omap5_uevm. > > Did you have other patches applied? master works here, but there's > some patches required for the USB stuff that haven't yet made it from > u-boot-arm to u-boot. > Yes, I had local changes, sorry for the noise.
Hi Gilles, > On 05/16/2013 10:39 AM, Lubomir Popov wrote: > >> Hi Gilles, >> >> On 16/05/13 01:31, Gilles Chanteperdrix wrote: >>> On 05/15/2013 05:55 PM, Lubomir Popov wrote: >>> >>>> Prerequisites: appropriate patches to the USB EHCI and Eth >>>> drivers, and to the OMAP5 clock register definitions. >>> >>> >>> Hi Lubomir, >>> >>> I have been trying to get the USB working on omap5 uEVM yesterday. In >>> addition to your code, I added the changes necessary to pinmux the 79 >>> and 80 GPIOS correctly, but it does not seem to work. I suspect there >>> is >>> something else missing than simply USB specific bits, because when the >>> ethernet phy is supposedly out of reset, the ethernet leds keep turned >>> off. I was thinking about checking the PMIC registers. >> PMIC wouldn't be related. > > > Hi, > > My idea was that if the ethernet chip does not power up, maybe it is > because some LDO or SMPS needs to be powered on. The board documentation > says for some LDOs that they are enabled on boot and does not say for > others, so that may be because they need to be enabled. Both USB devices are powered by VCC_3V3_MAIN, provided by an external SMPS chip (U3). With the default configuration of the uEVM, this SMPS turns on whenever DC wall power is present; the other option - control by the PMIC SYSEN1 output, has no relation to software as well (SYSEN1 is driven by the PMIC power-on/off sequencer, which is burnt into the PMIC EPROM. Upon power-on it goes high at the very beginning of the sequence). So, unfortunately, this could not be the cause. Regarding the Ethernet LEDs, as far as I remember, they didn't light up at all, although Ethernet worked. The smsc95xx driver in u-boot supports the LAN9730 in compatibility mode and probably does not setup LED operation properly. > >> >> Did you pull the current u-boot master and then apply the following >> patches >> before testing? Eager to know ;) >> >> http://patchwork.ozlabs.org/patch/232742/ >> http://patchwork.ozlabs.org/patch/244100/ > > > I was working with u-boot-ti master, applied all the patches, and it > still does not seem to work. I just tried the u-boot master branch but > it fails to compile for omap5_uevm. I think mainline u-boot master still lacks another vital patch for OMAP5 USB, which has been applied to u-boot-ti only (this is commit 2bcc785a1e8ffd3783c2116837fb4b4866a70cef). So please stay with the ti branch for now. Don't know what to say; it's a pity that I don't have the hardware at hand. One more thing that I would suggest to try: remove the patch from ehci-hcd.c that calls the HSIC device reset function for OMAP5. The essence is one line, a function call: omap5_ehci_hsic_reset_device(le16_to_cpu(req->index)); Just comment it out. It is fairly possible that on ES2.0 this workaround is not needed anymore (although I don't recall anything on the subject in the Silicon Errata docs). I have tested on ES1.0 only, so it has to be verified that this patch doesn't have a negative impact on ES2.0. > > Regards. > > -- > Gilles. > Best regards, Lubo
On 05/18/2013 09:13 PM, Lubomir Popov wrote: > Hi Gilles, > >> On 05/16/2013 10:39 AM, Lubomir Popov wrote: >> >>> Hi Gilles, >>> >>> On 16/05/13 01:31, Gilles Chanteperdrix wrote: >>>> On 05/15/2013 05:55 PM, Lubomir Popov wrote: >>>> >>>>> Prerequisites: appropriate patches to the USB EHCI and Eth >>>>> drivers, and to the OMAP5 clock register definitions. >>>> >>>> >>>> Hi Lubomir, >>>> >>>> I have been trying to get the USB working on omap5 uEVM yesterday. In >>>> addition to your code, I added the changes necessary to pinmux the 79 >>>> and 80 GPIOS correctly, but it does not seem to work. I suspect there >>>> is >>>> something else missing than simply USB specific bits, because when the >>>> ethernet phy is supposedly out of reset, the ethernet leds keep turned >>>> off. I was thinking about checking the PMIC registers. >>> PMIC wouldn't be related. >> >> >> Hi, >> >> My idea was that if the ethernet chip does not power up, maybe it is >> because some LDO or SMPS needs to be powered on. The board documentation >> says for some LDOs that they are enabled on boot and does not say for >> others, so that may be because they need to be enabled. > Both USB devices are powered by VCC_3V3_MAIN, provided by an external SMPS > chip (U3). With the default configuration of the uEVM, this SMPS turns on > whenever DC wall power is present; the other option - control by the PMIC > SYSEN1 output, has no relation to software as well (SYSEN1 is driven by > the PMIC power-on/off sequencer, which is burnt into the PMIC EPROM. Upon > power-on it goes high at the very beginning of the sequence). So, > unfortunately, this could not be the cause. > Regarding the Ethernet LEDs, as far as I remember, they didn't light up at > all, although Ethernet worked. The smsc95xx driver in u-boot supports the > LAN9730 in compatibility mode and probably does not setup LED operation > properly. Reading the schematics, it seems to me that the ethernet reset arrives on a component using 1.8V which if I am not mistaken comes from the PMIC SMPS7.
> On 05/18/2013 09:13 PM, Lubomir Popov wrote: > >> Hi Gilles, >> >>> On 05/16/2013 10:39 AM, Lubomir Popov wrote: >>> >>>> Hi Gilles, >>>> >>>> On 16/05/13 01:31, Gilles Chanteperdrix wrote: >>>>> On 05/15/2013 05:55 PM, Lubomir Popov wrote: >>>>> >>>>>> Prerequisites: appropriate patches to the USB EHCI and Eth >>>>>> drivers, and to the OMAP5 clock register definitions. >>>>> >>>>> >>>>> Hi Lubomir, >>>>> >>>>> I have been trying to get the USB working on omap5 uEVM yesterday. In >>>>> addition to your code, I added the changes necessary to pinmux the 79 >>>>> and 80 GPIOS correctly, but it does not seem to work. I suspect there >>>>> is >>>>> something else missing than simply USB specific bits, because when >>>>> the >>>>> ethernet phy is supposedly out of reset, the ethernet leds keep >>>>> turned >>>>> off. I was thinking about checking the PMIC registers. >>>> PMIC wouldn't be related. >>> >>> >>> Hi, >>> >>> My idea was that if the ethernet chip does not power up, maybe it is >>> because some LDO or SMPS needs to be powered on. The board >>> documentation >>> says for some LDOs that they are enabled on boot and does not say for >>> others, so that may be because they need to be enabled. >> Both USB devices are powered by VCC_3V3_MAIN, provided by an external >> SMPS >> chip (U3). With the default configuration of the uEVM, this SMPS turns >> on >> whenever DC wall power is present; the other option - control by the >> PMIC >> SYSEN1 output, has no relation to software as well (SYSEN1 is driven by >> the PMIC power-on/off sequencer, which is burnt into the PMIC EPROM. >> Upon >> power-on it goes high at the very beginning of the sequence). So, >> unfortunately, this could not be the cause. >> Regarding the Ethernet LEDs, as far as I remember, they didn't light up >> at >> all, although Ethernet worked. The smsc95xx driver in u-boot supports >> the >> LAN9730 in compatibility mode and probably does not setup LED operation >> properly. > > > Reading the schematics, it seems to me that the ethernet reset arrives > on a component using 1.8V which if I am not mistaken comes from the PMIC > SMPS7. > Well, this (1.8 V) is the main I/O supply of the OMAP and most peripherals; if it were not OK, the board wouldn't work at all. > -- > Gilles. > BR Lubo
On 05/18/2013 09:13 PM, Lubomir Popov wrote: > Hi Gilles, > >> On 05/16/2013 10:39 AM, Lubomir Popov wrote: >> >>> Hi Gilles, >>> >>> On 16/05/13 01:31, Gilles Chanteperdrix wrote: >>>> On 05/15/2013 05:55 PM, Lubomir Popov wrote: >>>> >>>>> Prerequisites: appropriate patches to the USB EHCI and Eth >>>>> drivers, and to the OMAP5 clock register definitions. >>>> >>>> >>>> Hi Lubomir, >>>> >>>> I have been trying to get the USB working on omap5 uEVM yesterday. In >>>> addition to your code, I added the changes necessary to pinmux the 79 >>>> and 80 GPIOS correctly, but it does not seem to work. I suspect there >>>> is >>>> something else missing than simply USB specific bits, because when the >>>> ethernet phy is supposedly out of reset, the ethernet leds keep turned >>>> off. I was thinking about checking the PMIC registers. >>> PMIC wouldn't be related. >> >> >> Hi, >> >> My idea was that if the ethernet chip does not power up, maybe it is >> because some LDO or SMPS needs to be powered on. The board documentation >> says for some LDOs that they are enabled on boot and does not say for >> others, so that may be because they need to be enabled. > Both USB devices are powered by VCC_3V3_MAIN, provided by an external SMPS > chip (U3). With the default configuration of the uEVM, this SMPS turns on > whenever DC wall power is present; the other option - control by the PMIC > SYSEN1 output, has no relation to software as well (SYSEN1 is driven by > the PMIC power-on/off sequencer, which is burnt into the PMIC EPROM. Upon > power-on it goes high at the very beginning of the sequence). So, > unfortunately, this could not be the cause. > Regarding the Ethernet LEDs, as far as I remember, they didn't light up at > all, although Ethernet worked. The smsc95xx driver in u-boot supports the > LAN9730 in compatibility mode and probably does not setup LED operation > properly. >> >>> >>> Did you pull the current u-boot master and then apply the following >>> patches >>> before testing? Eager to know ;) >>> >>> http://patchwork.ozlabs.org/patch/232742/ >>> http://patchwork.ozlabs.org/patch/244100/ >> >> >> I was working with u-boot-ti master, applied all the patches, and it >> still does not seem to work. I just tried the u-boot master branch but >> it fails to compile for omap5_uevm. > I think mainline u-boot master still lacks another vital patch for OMAP5 > USB, which has been applied to u-boot-ti only (this is commit > 2bcc785a1e8ffd3783c2116837fb4b4866a70cef). So please stay with the ti > branch for now. > Don't know what to say; it's a pity that I don't have the hardware at hand. It does not really matter, I can use the SD card to copy my kernels for now. It is a bit less convenient than TFTP, but still works. > One more thing that I would suggest to try: remove the patch from ehci-hcd.c > that calls the HSIC device reset function for OMAP5. The essence is one > line, a function call: > > omap5_ehci_hsic_reset_device(le16_to_cpu(req->index)); > > Just comment it out. It is fairly possible that on ES2.0 this workaround is > not needed anymore (although I don't recall anything on the subject in the > Silicon Errata docs). I have tested on ES1.0 only, so it has to be > verified that this patch doesn't have a negative impact on ES2.0. No, it does not seem to make any difference.
diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c index 46db1bf..3144fba 100644 --- a/board/ti/omap5_uevm/evm.c +++ b/board/ti/omap5_uevm/evm.c @@ -26,13 +26,20 @@ #include <palmas.h> #include <asm/arch/sys_proto.h> #include <asm/arch/mmc_host_def.h> +#include <asm/omap_common.h> #include "mux_data.h" +#ifdef CONFIG_USB_EHCI +#include <usb.h> +#include <asm/arch/ehci.h> +#include <asm/ehci-omap.h> +#endif + DECLARE_GLOBAL_DATA_PTR; const struct omap_sysinfo sysinfo = { - "Board: OMAP5430 EVM\n" + "Board: OMAP5432 uEVM\n" }; /** @@ -99,3 +106,53 @@ int board_mmc_init(bd_t *bis) return 0; } #endif + +#ifdef CONFIG_USB_EHCI +static struct omap_usbhs_board_data usbhs_bdata = { + .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED, + .port_mode[1] = OMAP_EHCI_PORT_MODE_HSIC, /* USB3503 hub */ + .port_mode[2] = OMAP_EHCI_PORT_MODE_HSIC, /* LAN9730 Ethernet */ +}; + +int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor **hcor) +{ + int ret; + + /* Enbale USB ports 2 & 3 UHH, UTMI and HSIC clocks */ + setbits_le32((*prcm)->cm_l3init_hsusbhost_clkctrl, + USB_HOST_HS_CLKCTRL_EN); + /* Enbale USB host ports TLL clocks */ + setbits_le32((*prcm)->cm_l3init_hsusbtll_clkctrl, + USB_TLL_HS_CLKCTRL_EN); + + /* + * The hub uses OMAP FREF_CLK1_OUT at 19.2 MHz. Use default source + * (SYS_CLK) and default divider of 1, so just turn it on. + */ + setbits_le32((*prcm)->scrm_auxclk1, AUXCLK_ENABLE_MASK); + udelay(1000); /* Let PLL lock */ + + ret = omap_ehci_hcd_init(&usbhs_bdata, hccr, hcor); + if (ret < 0) + return ret; + + return 0; +} + +int ehci_hcd_stop(void) +{ + int ret; + + ret = omap_ehci_hcd_stop(); + + clrbits_le32((*prcm)->cm_l3init_hsusbhost_clkctrl, + USB_HOST_HS_CLKCTRL_EN); + clrbits_le32((*prcm)->cm_l3init_hsusbtll_clkctrl, + USB_TLL_HS_CLKCTRL_EN); + + /* Stop FREF_CLK1_OUT */ + clrbits_le32((*prcm)->scrm_auxclk1, AUXCLK_ENABLE_MASK); + return ret; +} +#endif /* CONFIG_USB_EHCI */ + diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h index c791789..e15dd99 100644 --- a/include/configs/omap5_uevm.h +++ b/include/configs/omap5_uevm.h @@ -52,7 +52,39 @@ #define CONFIG_PARTITION_UUIDS #define CONFIG_CMD_PART -#define CONFIG_SYS_PROMPT "OMAP5430 EVM # " +/* USB UHH support options */ +#define CONFIG_CMD_USB +#define CONFIG_USB_HOST +#define CONFIG_USB_EHCI +#define CONFIG_USB_EHCI_OMAP +#define CONFIG_USB_STORAGE +#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 + +/* + * Due to OMAP5 HSIC connect ussues, device reset is required + * upon applying port power. A GPIO is needed per HSIC device: + */ +#define CONFIG_OMAP_HSIC_PORT2_RESET_GPIO 80 /* USB 3-port hub */ +#define CONFIG_OMAP_HSIC_PORT3_RESET_GPIO 79 /* Ethernet Ctrlr */ + +/* + * Enable bit fields for USB ports 2 & 3 HS clocks setup in regs + * cm_l3init_hsusbhost_clkctrl and cm_l3init_hsusbtll_clkctrl: + */ +#define USB_HOST_HS_CLKCTRL_EN 0x0000d6c0 +#define USB_TLL_HS_CLKCTRL_EN 0x00000600 + +/* USB Networking options */ +#define CONFIG_USB_HOST_ETHER +#define CONFIG_USB_ETHER_SMSC95XX + +/* Enabled commands */ +#define CONFIG_CMD_NET /* bootp, tftpboot, rarpboot */ +#define CONFIG_CMD_NFS /* NFS support */ +#define CONFIG_CMD_DHCP /* DHCP support */ +#define CONFIG_CMD_PING /* PING support */ + +#define CONFIG_SYS_PROMPT "OMAP5432 uEVM # " #define CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC 16296 #endif /* __CONFIG_OMAP5_EVM_H */
Prerequisites: appropriate patches to the USB EHCI and Eth drivers, and to the OMAP5 clock register definitions. Signed-off-by: Lubomir Popov <lpopov@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. board/ti/omap5_uevm/evm.c | 59 +++++++++++++++++++++++++++++++++++++++++- include/configs/omap5_uevm.h | 34 +++++++++++++++++++++++- 2 files changed, 91 insertions(+), 2 deletions(-)