Patchwork [U-Boot,RFC] OMAP5: uEVM: Enable USB EHCI functionality (preliminary, not tested)

login
register
mail settings
Submitter Lubomir Popov
Date May 15, 2013, 3:55 p.m.
Message ID <5193AFEC.60700@mm-sol.com>
Download mbox | patch
Permalink /patch/244124/
State Superseded
Delegated to: Tom Rini
Headers show

Comments

Lubomir Popov - May 15, 2013, 3:55 p.m.
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(-)
Nishanth Menon - May 15, 2013, 4:09 p.m.
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.
Tom Rini - May 15, 2013, 10:06 p.m.
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.
Gilles Chanteperdrix - May 15, 2013, 10:31 p.m.
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.
Gilles Chanteperdrix - May 15, 2013, 10:33 p.m.
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
Lubomir Popov - May 16, 2013, 8:23 a.m.
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
Lubomir Popov - May 16, 2013, 8:39 a.m.
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
Tom Rini - May 16, 2013, 12:28 p.m.
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.
Lubomir Popov - May 16, 2013, 2:56 p.m.
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
Tom Rini - May 16, 2013, 3:29 p.m.
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..
Lubomir Popov - May 16, 2013, 6:43 p.m.
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.

>
SRICHARAN R - May 17, 2013, 5:34 a.m.
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
Lubomir Popov - May 17, 2013, 9:35 a.m.
> 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
Tom Rini - May 17, 2013, 1:52 p.m.
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
...
Gilles Chanteperdrix - May 18, 2013, 3:25 p.m.
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.
Tom Rini - May 18, 2013, 5:07 p.m.
-----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-----
Gilles Chanteperdrix - May 18, 2013, 5:12 p.m.
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.
Lubomir Popov - May 18, 2013, 7:13 p.m.
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
Gilles Chanteperdrix - May 18, 2013, 7:16 p.m.
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.
Lubomir Popov - May 18, 2013, 7:24 p.m.
> 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
Gilles Chanteperdrix - May 18, 2013, 8:46 p.m.
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.

Patch

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 */