[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

On Beagle xM Rev. Ax/Bx, the USB power enable GPIO logic is
reversed when compared to other revisions i.e. it is
active high instead of active low.

Use the beagle_config.usb_pwr_level flag correctly so that
the power regulator can be configured at runtime.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 arch/arm/mach-omap2/board-omap3beagle.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 5382215..21136b2 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -112,13 +112,13 @@ static u8 omap3_beagle_version;
  */
 static struct {
 	int mmc1_gpio_wp;
-	int usb_pwr_level;
+	bool usb_pwr_level;	/* 0 - Active Low, 1 - Active High */
 	int dvi_pd_gpio;
 	int usr_button_gpio;
 	int mmc_caps;
 } beagle_config = {
 	.mmc1_gpio_wp = -EINVAL,
-	.usb_pwr_level = GPIOF_OUT_INIT_LOW,
+	.usb_pwr_level = 0,
 	.dvi_pd_gpio = -EINVAL,
 	.usr_button_gpio = 4,
 	.mmc_caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
@@ -178,7 +178,7 @@ static void __init omap3_beagle_init_rev(void)
 	case 0:
 		printk(KERN_INFO "OMAP3 Beagle Rev: xM Ax/Bx\n");
 		omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
-		beagle_config.usb_pwr_level = GPIOF_OUT_INIT_HIGH;
+		beagle_config.usb_pwr_level = 1;
 		beagle_config.mmc_caps &= ~MMC_CAP_8_BIT_DATA;
 		break;
 	case 2:
-- 
1.7.4.1

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

On Beagle xM Rev. Ax/Bx, the USB power enable GPIO logic is
reversed when compared to other revisions i.e. it is
active high instead of active low.

Use the beagle_config.usb_pwr_level flag correctly so that
the power regulator can be configured at runtime.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 arch/arm/mach-omap2/board-omap3beagle.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 5382215..21136b2 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -112,13 +112,13 @@ static u8 omap3_beagle_version;
  */
 static struct {
 	int mmc1_gpio_wp;
-	int usb_pwr_level;
+	bool usb_pwr_level;	/* 0 - Active Low, 1 - Active High */
 	int dvi_pd_gpio;
 	int usr_button_gpio;
 	int mmc_caps;
 } beagle_config = {
 	.mmc1_gpio_wp = -EINVAL,
-	.usb_pwr_level = GPIOF_OUT_INIT_LOW,
+	.usb_pwr_level = 0,
 	.dvi_pd_gpio = -EINVAL,
 	.usr_button_gpio = 4,
 	.mmc_caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
@@ -178,7 +178,7 @@ static void __init omap3_beagle_init_rev(void)
 	case 0:
 		printk(KERN_INFO "OMAP3 Beagle Rev: xM Ax/Bx\n");
 		omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
-		beagle_config.usb_pwr_level = GPIOF_OUT_INIT_HIGH;
+		beagle_config.usb_pwr_level = 1;
 		beagle_config.mmc_caps &= ~MMC_CAP_8_BIT_DATA;
 		break;
 	case 2:
-- 
1.7.4.1

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

On Beagle xM Rev. Ax/Bx, the USB power enable GPIO logic is
reversed when compared to other revisions i.e. it is
active high instead of active low.

Use the beagle_config.usb_pwr_level flag correctly so that
the power regulator can be configured at runtime.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 arch/arm/mach-omap2/board-omap3beagle.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 5382215..21136b2 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -112,13 +112,13 @@ static u8 omap3_beagle_version;
  */
 static struct {
 	int mmc1_gpio_wp;
-	int usb_pwr_level;
+	bool usb_pwr_level;	/* 0 - Active Low, 1 - Active High */
 	int dvi_pd_gpio;
 	int usr_button_gpio;
 	int mmc_caps;
 } beagle_config = {
 	.mmc1_gpio_wp = -EINVAL,
-	.usb_pwr_level = GPIOF_OUT_INIT_LOW,
+	.usb_pwr_level = 0,
 	.dvi_pd_gpio = -EINVAL,
 	.usr_button_gpio = 4,
 	.mmc_caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
@@ -178,7 +178,7 @@ static void __init omap3_beagle_init_rev(void)
 	case 0:
 		printk(KERN_INFO "OMAP3 Beagle Rev: xM Ax/Bx\n");
 		omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
-		beagle_config.usb_pwr_level = GPIOF_OUT_INIT_HIGH;
+		beagle_config.usb_pwr_level = 1;
 		beagle_config.mmc_caps &= ~MMC_CAP_8_BIT_DATA;
 		break;
 	case 2:
-- 
1.7.4.1

Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Tony Lindgren]

* Roger Quadros <rogerq@ti.com> [130415 04:25]:
> On Beagle xM Rev. Ax/Bx, the USB power enable GPIO logic is
> reversed when compared to other revisions i.e. it is
> active high instead of active low.
> 
> Use the beagle_config.usb_pwr_level flag correctly so that
> the power regulator can be configured at runtime.
> 
> Signed-off-by: Roger Quadros <rogerq@ti.com>

Thanks applying into omap-for-v3.10/fixes.

Regards,

Tony

> ---
>  arch/arm/mach-omap2/board-omap3beagle.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
> index 5382215..21136b2 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -112,13 +112,13 @@ static u8 omap3_beagle_version;
>   */
>  static struct {
>  	int mmc1_gpio_wp;
> -	int usb_pwr_level;
> +	bool usb_pwr_level;	/* 0 - Active Low, 1 - Active High */
>  	int dvi_pd_gpio;
>  	int usr_button_gpio;
>  	int mmc_caps;
>  } beagle_config = {
>  	.mmc1_gpio_wp = -EINVAL,
> -	.usb_pwr_level = GPIOF_OUT_INIT_LOW,
> +	.usb_pwr_level = 0,
>  	.dvi_pd_gpio = -EINVAL,
>  	.usr_button_gpio = 4,
>  	.mmc_caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
> @@ -178,7 +178,7 @@ static void __init omap3_beagle_init_rev(void)
>  	case 0:
>  		printk(KERN_INFO "OMAP3 Beagle Rev: xM Ax/Bx\n");
>  		omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
> -		beagle_config.usb_pwr_level = GPIOF_OUT_INIT_HIGH;
> +		beagle_config.usb_pwr_level = 1;
>  		beagle_config.mmc_caps &= ~MMC_CAP_8_BIT_DATA;
>  		break;
>  	case 2:
> -- 
> 1.7.4.1
> 

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Tony Lindgren]

* Roger Quadros <rogerq@ti.com> [130415 04:25]:
> On Beagle xM Rev. Ax/Bx, the USB power enable GPIO logic is
> reversed when compared to other revisions i.e. it is
> active high instead of active low.
> 
> Use the beagle_config.usb_pwr_level flag correctly so that
> the power regulator can be configured at runtime.
> 
> Signed-off-by: Roger Quadros <rogerq@ti.com>

Thanks applying into omap-for-v3.10/fixes.

Regards,

Tony

> ---
>  arch/arm/mach-omap2/board-omap3beagle.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
> index 5382215..21136b2 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -112,13 +112,13 @@ static u8 omap3_beagle_version;
>   */
>  static struct {
>  	int mmc1_gpio_wp;
> -	int usb_pwr_level;
> +	bool usb_pwr_level;	/* 0 - Active Low, 1 - Active High */
>  	int dvi_pd_gpio;
>  	int usr_button_gpio;
>  	int mmc_caps;
>  } beagle_config = {
>  	.mmc1_gpio_wp = -EINVAL,
> -	.usb_pwr_level = GPIOF_OUT_INIT_LOW,
> +	.usb_pwr_level = 0,
>  	.dvi_pd_gpio = -EINVAL,
>  	.usr_button_gpio = 4,
>  	.mmc_caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
> @@ -178,7 +178,7 @@ static void __init omap3_beagle_init_rev(void)
>  	case 0:
>  		printk(KERN_INFO "OMAP3 Beagle Rev: xM Ax/Bx\n");
>  		omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
> -		beagle_config.usb_pwr_level = GPIOF_OUT_INIT_HIGH;
> +		beagle_config.usb_pwr_level = 1;
>  		beagle_config.mmc_caps &= ~MMC_CAP_8_BIT_DATA;
>  		break;
>  	case 2:
> -- 
> 1.7.4.1
> 

Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Stefan Roese]

Roger,

On 04/15/2013 01:20 PM, Roger Quadros wrote:
> On Beagle xM Rev. Ax/Bx, the USB power enable GPIO logic is
> reversed when compared to other revisions i.e. it is
> active high instead of active low.
> 
> Use the beagle_config.usb_pwr_level flag correctly so that
> the power regulator can be configured at runtime.
> 
> Signed-off-by: Roger Quadros <rogerq@ti.com>

I'm currently trying to use an SMSC95xx USB ethernet adapter on the
OMAP3 Beagleboard (old one "Beagle Rev C1/C2/C3") via the OMAP EHCI
controller. And am testing this by trying to mount the rootfs via NFS.
What I see is that the NFS mounting stalls/hangs most of the time quite
early in the mount process:

[    6.425689] VFS: Mounted root (nfs filesystem) on device 0:12.
[    6.435485] devtmpfs: mounted
[    6.440002] Freeing unused kernel memory: 384K (c077a000 - c07da000)
INIT: version 2.88 booting
Starting udev
[  188.311309] nfs: server 10.0.0.152 not responding, still trying
[  188.317687] nfs: server 10.0.0.152 not responding, still trying
...

Only very seldom the rootfs can be mounted successfully to the prompt.

I'm using latest kernel.org for this (git ID d2b4a646 also tested with
v3.10 release). This is with DT-enabled booting and without-DT (same
problem). I also tested some older Linux kernel versions and it fails
there as well. Only v3.2.40 seems to be able to mount this rootfs via
NFS reliably (approx. 10 times success).

Is this a known issue on the Beagleboard? Do you have any ideas what
might cause such an issue (unreliable USB connection, hangup of NFS
mounting)? Any hints/links appretiated.

Thanks,
Stefan

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Stefan Roese]

Roger,

On 04/15/2013 01:20 PM, Roger Quadros wrote:
> On Beagle xM Rev. Ax/Bx, the USB power enable GPIO logic is
> reversed when compared to other revisions i.e. it is
> active high instead of active low.
> 
> Use the beagle_config.usb_pwr_level flag correctly so that
> the power regulator can be configured at runtime.
> 
> Signed-off-by: Roger Quadros <rogerq@ti.com>

I'm currently trying to use an SMSC95xx USB ethernet adapter on the
OMAP3 Beagleboard (old one "Beagle Rev C1/C2/C3") via the OMAP EHCI
controller. And am testing this by trying to mount the rootfs via NFS.
What I see is that the NFS mounting stalls/hangs most of the time quite
early in the mount process:

[    6.425689] VFS: Mounted root (nfs filesystem) on device 0:12.
[    6.435485] devtmpfs: mounted
[    6.440002] Freeing unused kernel memory: 384K (c077a000 - c07da000)
INIT: version 2.88 booting
Starting udev
[  188.311309] nfs: server 10.0.0.152 not responding, still trying
[  188.317687] nfs: server 10.0.0.152 not responding, still trying
...

Only very seldom the rootfs can be mounted successfully to the prompt.

I'm using latest kernel.org for this (git ID d2b4a646 also tested with
v3.10 release). This is with DT-enabled booting and without-DT (same
problem). I also tested some older Linux kernel versions and it fails
there as well. Only v3.2.40 seems to be able to mount this rootfs via
NFS reliably (approx. 10 times success).

Is this a known issue on the Beagleboard? Do you have any ideas what
might cause such an issue (unreliable USB connection, hangup of NFS
mounting)? Any hints/links appretiated.

Thanks,
Stefan

Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

Hi Stefan,

On 07/09/2013 04:02 PM, Stefan Roese wrote:
> Roger,
> 
> On 04/15/2013 01:20 PM, Roger Quadros wrote:
>> On Beagle xM Rev. Ax/Bx, the USB power enable GPIO logic is
>> reversed when compared to other revisions i.e. it is
>> active high instead of active low.
>>
>> Use the beagle_config.usb_pwr_level flag correctly so that
>> the power regulator can be configured at runtime.
>>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
> 
> I'm currently trying to use an SMSC95xx USB ethernet adapter on the
> OMAP3 Beagleboard (old one "Beagle Rev C1/C2/C3") via the OMAP EHCI
> controller. And am testing this by trying to mount the rootfs via NFS.
> What I see is that the NFS mounting stalls/hangs most of the time quite
> early in the mount process:
> 
> [    6.425689] VFS: Mounted root (nfs filesystem) on device 0:12.
> [    6.435485] devtmpfs: mounted
> [    6.440002] Freeing unused kernel memory: 384K (c077a000 - c07da000)
> INIT: version 2.88 booting
> Starting udev
> [  188.311309] nfs: server 10.0.0.152 not responding, still trying
> [  188.317687] nfs: server 10.0.0.152 not responding, still trying
> ...
> 
> Only very seldom the rootfs can be mounted successfully to the prompt.
> 
> I'm using latest kernel.org for this (git ID d2b4a646 also tested with
> v3.10 release). This is with DT-enabled booting and without-DT (same
> problem). I also tested some older Linux kernel versions and it fails
> there as well. Only v3.2.40 seems to be able to mount this rootfs via
> NFS reliably (approx. 10 times success).

I can't really tell at the moment where the problem is.

Did you compile in all the necessary drivers required for NFS booting?
In the beagle case that would mean NOP_USB_XCEIV, USB_EHCI_HCD, USB_EHCI_HCD_OMAP
and the smsc95xx driver.

If you can paste your full kernel boot log we can check if all these show up
before the kernel tries to look up for the NFS server.
> 
> Is this a known issue on the Beagleboard? Do you have any ideas what
> might cause such an issue (unreliable USB connection, hangup of NFS
> mounting)? Any hints/links appretiated.
> 

I have been too lazy to setup NFS :). But I will give it a shot soon to see what's going
wrong.

cheers,
-roger

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

Hi Stefan,

On 07/09/2013 04:02 PM, Stefan Roese wrote:
> Roger,
> 
> On 04/15/2013 01:20 PM, Roger Quadros wrote:
>> On Beagle xM Rev. Ax/Bx, the USB power enable GPIO logic is
>> reversed when compared to other revisions i.e. it is
>> active high instead of active low.
>>
>> Use the beagle_config.usb_pwr_level flag correctly so that
>> the power regulator can be configured at runtime.
>>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
> 
> I'm currently trying to use an SMSC95xx USB ethernet adapter on the
> OMAP3 Beagleboard (old one "Beagle Rev C1/C2/C3") via the OMAP EHCI
> controller. And am testing this by trying to mount the rootfs via NFS.
> What I see is that the NFS mounting stalls/hangs most of the time quite
> early in the mount process:
> 
> [    6.425689] VFS: Mounted root (nfs filesystem) on device 0:12.
> [    6.435485] devtmpfs: mounted
> [    6.440002] Freeing unused kernel memory: 384K (c077a000 - c07da000)
> INIT: version 2.88 booting
> Starting udev
> [  188.311309] nfs: server 10.0.0.152 not responding, still trying
> [  188.317687] nfs: server 10.0.0.152 not responding, still trying
> ...
> 
> Only very seldom the rootfs can be mounted successfully to the prompt.
> 
> I'm using latest kernel.org for this (git ID d2b4a646 also tested with
> v3.10 release). This is with DT-enabled booting and without-DT (same
> problem). I also tested some older Linux kernel versions and it fails
> there as well. Only v3.2.40 seems to be able to mount this rootfs via
> NFS reliably (approx. 10 times success).

I can't really tell at the moment where the problem is.

Did you compile in all the necessary drivers required for NFS booting?
In the beagle case that would mean NOP_USB_XCEIV, USB_EHCI_HCD, USB_EHCI_HCD_OMAP
and the smsc95xx driver.

If you can paste your full kernel boot log we can check if all these show up
before the kernel tries to look up for the NFS server.
> 
> Is this a known issue on the Beagleboard? Do you have any ideas what
> might cause such an issue (unreliable USB connection, hangup of NFS
> mounting)? Any hints/links appretiated.
> 

I have been too lazy to setup NFS :). But I will give it a shot soon to see what's going
wrong.

cheers,
-roger

Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

On 07/09/2013 05:16 PM, Stefan Roese wrote:
> Hi Roger,
> 
> On 07/09/2013 03:55 PM, Roger Quadros wrote:
>>> I'm using latest kernel.org for this (git ID d2b4a646 also tested with
>>> v3.10 release). This is with DT-enabled booting and without-DT (same
>>> problem). I also tested some older Linux kernel versions and it fails
>>> there as well. Only v3.2.40 seems to be able to mount this rootfs via
>>> NFS reliably (approx. 10 times success).
>>
>> I can't really tell at the moment where the problem is.
>>
>> Did you compile in all the necessary drivers required for NFS booting?
>> In the beagle case that would mean NOP_USB_XCEIV, USB_EHCI_HCD, USB_EHCI_HCD_OMAP
>> and the smsc95xx driver.
> 
> Yes, sure. Otherwise no USB/NFS mount would have been possible.
> 
>> If you can paste your full kernel boot log we can check if all these show up
>> before the kernel tries to look up for the NFS server.
> 
> Please find it attached (one log for the NFS mount working and one for
> failing - both with exact the same kernel/dtb). Also my current .config.
> 

Thanks for the logs. Configuration part seems OK. NFS root has been mounted
in failing case as well. Then it fails. I'll need to investigate more what
happens. 

cheers,
-roger

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

On 07/09/2013 05:16 PM, Stefan Roese wrote:
> Hi Roger,
> 
> On 07/09/2013 03:55 PM, Roger Quadros wrote:
>>> I'm using latest kernel.org for this (git ID d2b4a646 also tested with
>>> v3.10 release). This is with DT-enabled booting and without-DT (same
>>> problem). I also tested some older Linux kernel versions and it fails
>>> there as well. Only v3.2.40 seems to be able to mount this rootfs via
>>> NFS reliably (approx. 10 times success).
>>
>> I can't really tell at the moment where the problem is.
>>
>> Did you compile in all the necessary drivers required for NFS booting?
>> In the beagle case that would mean NOP_USB_XCEIV, USB_EHCI_HCD, USB_EHCI_HCD_OMAP
>> and the smsc95xx driver.
> 
> Yes, sure. Otherwise no USB/NFS mount would have been possible.
> 
>> If you can paste your full kernel boot log we can check if all these show up
>> before the kernel tries to look up for the NFS server.
> 
> Please find it attached (one log for the NFS mount working and one for
> failing - both with exact the same kernel/dtb). Also my current .config.
> 

Thanks for the logs. Configuration part seems OK. NFS root has been mounted
in failing case as well. Then it fails. I'll need to investigate more what
happens. 

cheers,
-roger

Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

On 07/09/2013 05:16 PM, Stefan Roese wrote:
> Hi Roger,
> 
>>
>> I have been too lazy to setup NFS :). But I will give it a shot soon to see what's going
>> wrong.
> 
> Really appreciated. :) Please let me know if you need anything else from
> me to reproduce this issue.

Stefan,

I tried it out today and it worked 5/5 times. I used a bare bones debian root filesystem for
the NFS root.

Could it be possible that the boot scripts on your filesystem are somehow shutting down
the ethernet interface? Might be worth checking on a fresh filesystem.

My u-boot script is below and boot log is attached.

setenv bootargs console=ttyO2,115200n8 root=/dev/nfs rw nfsroot=192.168.2.1:/srv/nfsroot/ ip=192.168.2.2 rootwait

setenv usbethaddr A6:66:4D:B0:69:04
setenv netmask 255.255.255.0
setenv ipaddr 192.168.2.2
setenv serverip 192.168.2.1

usb start

tftpboot 0x825f0000 omap3-beagle.dtb
tftpboot 0x80300000 uImage
set fdt_high 0xffffffff

bootm 0x80300000 - 0x825f0000

cheers,
-roger


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: nfs-boot.log --]
[-- Type: text/x-log; name="nfs-boot.log", Size: 19655 bytes --]


U-Boot SPL 2013.01-rc1-00080-gdfc050a (Apr 17 2013 - 15:06:06)
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img


U-Boot 2013.01-rc1-00080-gdfc050a (Apr 17 2013 - 15:06:06)

OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  512 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment

In:    serial
Out:   serial
Err:   serial
Beagle xM Rev C
No EEPROM on expansion board
Die ID #700a00229ff80000016842c91300d00e
Net:   Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot:  3 \b\b\b 2 \b\b\b 1 \b\b\b 0 
mmc0 is current device
reading boot.scr
440 bytes read
Running bootscript from mmc0 ...
## Executing script at 82000000
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 3 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
       scanning usb for ethernet devices... 1 Ethernet Device(s) found
Waiting for Ethernet connection... done.
Using sms0 device
TFTP from server 192.168.2.1; our IP address is 192.168.2.2
Filename 'omap3-beagle.dtb'.
Load address: 0x825f0000
Loading: *\bEHCI timed out on TD - token=0x8008d80
T #
done
Bytes transferred = 13169 (3371 hex)
Waiting for Ethernet connection... done.
Using sms0 device
TFTP from server 192.168.2.1; our IP address is 192.168.2.2
Filename 'uImage'.
Load address: 0x80300000
Loading: *\b#################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 ###################
done
Bytes transferred = 4088512 (3e62c0 hex)
Unknown command 'set' - try 'help'
## Booting kernel from Legacy Image at 80300000 ...
   Image Name:   Linux-3.10.0-08610-g8e1cacd
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4088448 Bytes = 3.9 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 825f0000
   Booting using the fdt blob at 0x825f0000
   Loading Kernel Image ... OK
OK
   Using Device Tree in place at 825f0000, end 825f6370

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.10.0-08610-g8e1cacd (roger@rockdesk) (gcc version 4.7.1 20120531 (prerelease) (crosstool-NG linaro-1.13.1-2012.06-20120625 - Linaro GCC 2012.06) ) #802 SMP Thu Jul 11 12:31:28 EEST 2013
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: Generic OMAP3 (Flattened Device Tree), model: TI OMAP3 BeagleBoard xM
[    0.000000] cma: CMA: reserved 16 MiB at 9e800000
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] CPU: All CPU(s) started in SVC mode.
[    0.000000] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk )
[    0.000000] PERCPU: Embedded 9 pages/cpu @c1188000 s14208 r8192 d14464 u36864
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129792
[    0.000000] Kernel command line: console=ttyO2,115200n8 root=/dev/nfs rw nfsroot=192.168.2.1:/srv/nfsroot/ ip=192.168.2.2 rootwait
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 488432K/523264K available (5305K kernel code, 611K rwdata, 1936K rodata, 381K init, 5522K bss, 34832K reserved, 0K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xe0800000 - 0xff000000   ( 488 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc071a9b8   (7243 kB)
[    0.000000]       .init : 0xc071b000 - 0xc077a780   ( 382 kB)
[    0.000000]       .data : 0xc077c000 - 0xc0814d40   ( 612 kB)
[    0.000000]        .bss : 0xc0814d40 - 0xc0d79778   (5523 kB)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts
[    0.000000] Total of 96 interrupts on 1 active controller
[    0.000000] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz
[    0.000000] OMAP clockevent source: timer1 at 32768 Hz
[    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
[    0.000000] OMAP clocksource: 32k_counter at 32768 Hz
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.001251] Calibrating delay loop... 395.67 BogoMIPS (lpj=1978368)
[    0.109710] pid_max: default: 32768 minimum: 301
[    0.110229] Security Framework initialized
[    0.110412] Mount-cache hash table entries: 512
[    0.125396] CPU: Testing write buffer coherency: ok
[    0.127014] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[    0.127075] Setting up static identity map for 0xc05073f0 - 0xc0507460
[    0.130859] Brought up 1 CPUs
[    0.130889] SMP: Total of 1 processors activated (395.67 BogoMIPS).
[    0.130889] CPU: All CPU(s) started in SVC mode.
[    0.134277] devtmpfs: initialized
[    0.207061] pinctrl core: initialized pinctrl subsystem
[    0.212371] regulator-dummy: no parameters
[    0.216186] NET: Registered protocol family 16
[    0.225585] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.242797] Reprogramming SDRC clock to 400000000 Hz
[    0.252624] omap_gpio 48310000.gpio: could not find pctldev for node /ocp/pinmux@0x48002a00/pinmux_gpio1_pins, deferring probe
[    0.252716] platform 48310000.gpio: Driver omap_gpio requests probe deferral
[    0.257598] OMAP GPIO hardware version 2.5
[    0.284698] platform 49022000.mcbsp: alias fck already exists
[    0.286071] platform 49024000.mcbsp: alias fck already exists
[    0.303131] omap-gpmc 6e000000.gpmc: GPMC revision 5.0
[    0.310791] No ATAGs?
[    0.310821] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.317413] OMAP DMA hardware revision 5.0
[    0.396270] bio: create slab <bio-0> at 0
[    0.491607] omap-dma-engine 48056000.dma-controller: OMAP DMA engine driver
[    0.494537] hsusb2_reset: 3300 mV 
[    0.495056] platform hsusb2_power_reg.23: Driver reg-fixed-voltage requests probe deferral
[    0.504364] SCSI subsystem initialized
[    0.507049] usbcore: registered new interface driver usbfs
[    0.507629] usbcore: registered new interface driver hub
[    0.508514] usbcore: registered new device driver usb
[    0.509613] platform hsusb2_phy.24: Driver nop_usb_xceiv requests probe deferral
[    0.512603] omap_i2c i2c.8: did not get pins for i2c error: -19
[    0.514678] omap_i2c i2c.8: bus 0 rev4.4 at 2600 kHz
[    0.516479] twl 0-0048: could not find pctldev for node /ocp/pinmux@48002030/pinmux_twl4030_pins, deferring probe
[    0.516571] i2c 0-0048: Driver twl requests probe deferral
[    0.516967] omap_i2c i2c.9: did not get pins for i2c error: -19
[    0.518341] omap_i2c i2c.9: bus 1 rev4.4 at 400 kHz
[    0.518585] omap_i2c i2c.10: did not get pins for i2c error: -19
[    0.520385] omap_i2c i2c.10: bus 2 rev4.4 at 100 kHz
[    0.532379] Switched to clocksource 32k_counter
[    0.695983] NET: Registered protocol family 2
[    0.698242] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[    0.698547] TCP bind hash table entries: 4096 (order: 5, 147456 bytes)
[    0.700805] TCP: Hash tables configured (established 4096 bind 4096)
[    0.701049] TCP: reno registered
[    0.701110] UDP hash table entries: 256 (order: 2, 20480 bytes)
[    0.701416] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[    0.703247] NET: Registered protocol family 1
[    0.705413] RPC: Registered named UNIX socket transport module.
[    0.705444] RPC: Registered udp transport module.
[    0.705444] RPC: Registered tcp transport module.
[    0.705474] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.706573] NetWinder Floating Point Emulator V0.97 (double precision)
[    0.706878] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
[    0.917663] VFS: Disk quotas dquot_6.5.2
[    0.917968] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.921142] NFS: Registering the id_resolver key type
[    0.921630] Key type id_resolver registered
[    0.921661] Key type id_legacy registered
[    0.921813] jffs2: version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
[    0.922546] msgmni has been set to 985
[    0.927062] io scheduler noop registered
[    0.927093] io scheduler deadline registered
[    0.927215] io scheduler cfq registered (default)
[    0.932250] pinctrl-single-omap 48002030.pinmux: 742 pins at pa fa002030 size 1484
[    0.933349] pinctrl-single-omap 48002a00.pinmux: 46 pins at pa fa002a00 size 92
[    0.938537] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.946838] omap_uart serial.5: did not get pins for uart0 error: -19
[    0.948120] serial.5: ttyO0 at MMIO 0x4806a000 (irq = 88) is a OMAP UART0
[    0.950592] omap_uart serial.6: did not get pins for uart1 error: -19
[    0.951171] serial.6: ttyO1 at MMIO 0x4806c000 (irq = 89) is a OMAP UART1
[    0.953918] serial.7: ttyO2 at MMIO 0x49020000 (irq = 90) is a OMAP UART2
[    1.701995] console [ttyO2] enabled
[    1.707702] omap_uart serial.17: did not get pins for uart3 error: -19
[    1.715301] serial.17: ttyO3 at MMIO 0x49042000 (irq = 96) is a OMAP UART3
[    1.761260] brd: module loaded
[    1.789031] loop: module loaded
[    1.806579] mtdoops: mtd device (mtddev=name/number) must be supplied
[    1.830200] usbcore: registered new interface driver asix
[    1.837097] usbcore: registered new interface driver ax88179_178a
[    1.844665] usbcore: registered new interface driver cdc_ether
[    1.851440] usbcore: registered new interface driver smsc95xx
[    1.858245] usbcore: registered new interface driver net1080
[    1.865081] usbcore: registered new interface driver cdc_subset
[    1.871856] usbcore: registered new interface driver zaurus
[    1.878540] usbcore: registered new interface driver cdc_ncm
[    1.886596] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.893768] ehci-omap: OMAP-EHCI Host Controller driver
[    1.900024] ehci-omap 48064800.ehci: Can't get PHY device for port 1: -517
[    1.907501] platform 48064800.ehci: Driver ehci-omap requests probe deferral
[    1.916290] usbcore: registered new interface driver cdc_wdm
[    1.923034] usbcore: registered new interface driver usb-storage
[    1.929962] usbcore: registered new interface driver usbtest
[    1.938568] mousedev: PS/2 mouse device common for all mice
[    1.950988] i2c /dev entries driver
[    1.959747] Driver for 1-wire Dallas network protocol.
[    1.970916] omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
[    1.983612] omap-dma-engine 48056000.dma-controller: allocating channel for 62
[    1.991363] omap-dma-engine 48056000.dma-controller: allocating channel for 61
[    1.999206] omap_hsmmc mmc.15: vmmc regulator missing
[    2.004913] omap-dma-engine 48056000.dma-controller: freeing channel for 61
[    2.012390] omap-dma-engine 48056000.dma-controller: freeing channel for 62
[    2.019836] platform mmc.15: Driver omap_hsmmc requests probe deferral
[    2.032989] ledtrig-cpu: registered to indicate activity on CPUs
[    2.041168] usbcore: registered new interface driver usbhid
[    2.047607] usbhid: USB HID core driver
[    2.053771] oprofile: using arm/armv7
[    2.058502] TCP: cubic registered
[    2.062042] Initializing XFRM netlink socket
[    2.066925] NET: Registered protocol family 17
[    2.071746] NET: Registered protocol family 15
[    2.076995] Key type dns_resolver registered
[    2.081634] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[    2.091979] ThumbEE CPU extension supported.
[    2.106811] platform hsusb2_power_reg.23: Driver reg-fixed-voltage requests probe deferral
[    2.116363] platform hsusb2_phy.24: Driver nop_usb_xceiv requests probe deferral
[    2.137878] twl 0-0048: PIH (irq 23) chaining IRQs 338..346
[    2.144592] twl 0-0048: power (irq 343) chaining IRQs 346..353
[    2.157409] twl_rtc rtc.26: Power up reset detected.
[    2.163055] twl_rtc rtc.26: Enabling TWL-RTC
[    2.173828] twl_rtc rtc.26: rtc core: registered rtc.26 as rtc0
[    2.187225] VDD1: 600 <--> 1450 mV at 1200 mV 
[    2.195861] VDAC: 1800 mV 
[    2.202056] VPLL2: 1800 mV 
[    2.208312] VMMC1: 1850 <--> 3150 mV at 3150 mV 
[    2.216278] VUSB1V5: 1500 mV 
[    2.221862] VUSB1V8: 1800 mV 
[    2.227844] VUSB3V1: 3100 mV 
[    2.233978] VSIM: 1800 <--> 3000 mV at 1800 mV 
[    2.242095] twl4030_gpio gpio.36: gpio (irq 338) chaining IRQs 354..371
[    2.255737] ehci-omap 48064800.ehci: Can't get PHY device for port 1: -517
[    2.263275] platform 48064800.ehci: Driver ehci-omap requests probe deferral
[    2.271820] omap-dma-engine 48056000.dma-controller: allocating channel for 62
[    2.279663] omap-dma-engine 48056000.dma-controller: allocating channel for 61
[    2.290863] omap_hsmmc mmc.15: pins configuration error: -19
[    2.297027] ------------[ cut here ]------------
[    2.301940] WARNING: CPU: 0 PID: 6 at kernel/irq/manage.c:1250 __free_irq+0x98/0x1c8()
[    2.310302] Trying to free already-free IRQ 0
[    2.314910] Modules linked in:
[    2.318176] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.10.0-08610-g8e1cacd #802
[    2.326293] Workqueue: deferwq deferred_probe_work_func
[    2.331848] [<c001b808>] (unwind_backtrace+0x0/0xf0) from [<c0017b64>] (show_stack+0x10/0x14)
[    2.340881] [<c0017b64>] (show_stack+0x10/0x14) from [<c04fc454>] (dump_stack+0x78/0x94)
[    2.349456] [<c04fc454>] (dump_stack+0x78/0x94) from [<c00440c8>] (warn_slowpath_common+0x68/0x8c)
[    2.358947] [<c00440c8>] (warn_slowpath_common+0x68/0x8c) from [<c0044180>] (warn_slowpath_fmt+0x30/0x40)
[    2.369079] [<c0044180>] (warn_slowpath_fmt+0x30/0x40) from [<c00a6d30>] (__free_irq+0x98/0x1c8)
[    2.378387] [<c00a6d30>] (__free_irq+0x98/0x1c8) from [<c00a6eac>] (free_irq+0x4c/0xa4)
[    2.386871] [<c00a6eac>] (free_irq+0x4c/0xa4) from [<c0416a00>] (omap_hsmmc_probe+0x648/0xed0)
[    2.395996] [<c0416a00>] (omap_hsmmc_probe+0x648/0xed0) from [<c0325924>] (platform_drv_probe+0x18/0x1c)
[    2.406036] [<c0325924>] (platform_drv_probe+0x18/0x1c) from [<c0324730>] (driver_probe_device+0x108/0x224)
[    2.416351] [<c0324730>] (driver_probe_device+0x108/0x224) from [<c0322d1c>] (bus_for_each_drv+0x44/0x8c)
[    2.426483] [<c0322d1c>] (bus_for_each_drv+0x44/0x8c) from [<c03245f0>] (device_attach+0x74/0x8c)
[    2.435882] [<c03245f0>] (device_attach+0x74/0x8c) from [<c0323c38>] (bus_probe_device+0x88/0xac)
[    2.445251] [<c0323c38>] (bus_probe_device+0x88/0xac) from [<c03240c0>] (deferred_probe_work_func+0x64/0x94)
[    2.455688] [<c03240c0>] (deferred_probe_work_func+0x64/0x94) from [<c005fa8c>] (process_one_work+0x1b4/0x4ac)
[    2.466278] [<c005fa8c>] (process_one_work+0x1b4/0x4ac) from [<c006017c>] (worker_thread+0x134/0x390)
[    2.476013] [<c006017c>] (worker_thread+0x134/0x390) from [<c00669dc>] (kthread+0xa4/0xb0)
[    2.484771] [<c00669dc>] (kthread+0xa4/0xb0) from [<c0013e48>] (ret_from_fork+0x14/0x2c)
[    2.493347] ---[ end trace cca2ac22e986a7fb ]---
[    2.499145] omap-dma-engine 48056000.dma-controller: freeing channel for 61
[    2.506622] omap-dma-engine 48056000.dma-controller: freeing channel for 62
[    2.517456] hsusb2_vbus: 3300 mV 
[    2.663269] ehci-omap 48064800.ehci: EHCI Host Controller
[    2.672515] ehci-omap 48064800.ehci: new USB bus registered, assigned bus number 1
[    2.682891] ehci-omap 48064800.ehci: irq 93, io mem 0x48064800
[    2.702850] ehci-omap 48064800.ehci: USB 2.0 started, EHCI 1.00
[    2.710174] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    2.717468] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.725128] usb usb1: Product: EHCI Host Controller
[    2.730285] usb usb1: Manufacturer: Linux 3.10.0-08610-g8e1cacd ehci_hcd
[    2.737396] usb usb1: SerialNumber: 48064800.ehci
[    2.748138] hub 1-0:1.0: USB hub found
[    2.752471] hub 1-0:1.0: 3 ports detected
[    2.765563] input: gpio_keys.21 as /devices/gpio_keys.21/input/input0
[    2.777557] twl_rtc rtc.26: setting system clock to 2000-01-01 00:00:00 UTC (946684800)
[    3.072845] usb 1-2: new high-speed USB device number 2 using ehci-omap
[    3.224121] usb 1-2: New USB device found, idVendor=0424, idProduct=9514
[    3.231201] usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    3.242675] hub 1-2:1.0: USB hub found
[    3.247039] hub 1-2:1.0: 5 ports detected
[    3.533264] usb 1-2.1: new high-speed USB device number 3 using ehci-omap
[    3.663848] usb 1-2.1: New USB device found, idVendor=0424, idProduct=ec00
[    3.671142] usb 1-2.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    3.684356] smsc95xx v1.0.4
[    3.778625] smsc95xx 1-2.1:1.0 eth0: register 'smsc95xx' at usb-48064800.ehci-2.1, smsc95xx USB 2.0 Ethernet, 4e:d2:dc:5e:15:12
[    3.875701] smsc95xx 1-2.1:1.0 eth0: hardware isn't capable of remote wakeup
[    5.340026] smsc95xx 1-2.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
[    5.362457] IP-Config: Guessing netmask 255.255.255.0
[    5.368377] IP-Config: Complete:
[    5.371887]      device=eth0, hwaddr=4e:d2:dc:5e:15:12, ipaddr=192.168.2.2, mask=255.255.255.0, gw=255.255.255.255
[    5.382873]      host=192.168.2.2, domain=, nis-domain=(none)
[    5.388946]      bootserver=255.255.255.255, rootserver=192.168.2.1, rootpath=
[   10.432098] VFS: Mounted root (nfs filesystem) on device 0:12.
[   10.441101] devtmpfs: mounted
[   10.445312] Freeing unused kernel memory: 380K (c071b000 - c077a000)
INIT: version 2.88 booting
[info] Using makefile-style concurrent boot in runlevel S.
[....] Starting the hotplug events dispatcher: udevd[   13.506683] udevd[866]: starting version 175
[ ok .
[....] Synthesizing the initial hotplug events...[ ok done.
[....] Waiting for /dev to be fully populated...[ ok done.
[....] Activating swap...[ ok done.
[....] Cleaning up temporary files... /tmp[ ok .
[....] Activating lvm and md swap...[ ok done.
[....] Checking file systems...fsck from util-linux 2.20.1
[ ok done.
[....] Mounting local filesystems...[ ok done.
[....] Activating swapfile swap...[ ok done.
[....] Cleaning up temporary files...[ ok .
[....] Cleaning up temporary files...[ ok .
[....] Setting kernel variables ...[ ok done.
INIT: Entering runlevel: 2
[info] Using makefile-style concurrent boot in runlevel 2.

Debian GNU/Linux 7.0 rockdesk ttyO2

rockdesk login: 

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

On 07/09/2013 05:16 PM, Stefan Roese wrote:
> Hi Roger,
> 
>>
>> I have been too lazy to setup NFS :). But I will give it a shot soon to see what's going
>> wrong.
> 
> Really appreciated. :) Please let me know if you need anything else from
> me to reproduce this issue.

Stefan,

I tried it out today and it worked 5/5 times. I used a bare bones debian root filesystem for
the NFS root.

Could it be possible that the boot scripts on your filesystem are somehow shutting down
the ethernet interface? Might be worth checking on a fresh filesystem.

My u-boot script is below and boot log is attached.

setenv bootargs console=ttyO2,115200n8 root=/dev/nfs rw nfsroot=192.168.2.1:/srv/nfsroot/ ip=192.168.2.2 rootwait

setenv usbethaddr A6:66:4D:B0:69:04
setenv netmask 255.255.255.0
setenv ipaddr 192.168.2.2
setenv serverip 192.168.2.1

usb start

tftpboot 0x825f0000 omap3-beagle.dtb
tftpboot 0x80300000 uImage
set fdt_high 0xffffffff

bootm 0x80300000 - 0x825f0000

cheers,
-roger

-------------- next part --------------
A non-text attachment was scrubbed...
Name: nfs-boot.log
Type: text/x-log
Size: 19655 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130711/dc853f1d/attachment-0001.bin>

Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Stefan Roese]

Hi Roger,

On 07/11/2013 12:24 PM, Roger Quadros wrote:
> Stefan,
> 
> I tried it out today and it worked 5/5 times. I used a bare bones
> debian root filesystem for
> the NFS root.

Thanks for testing.

> Could it be possible that the boot scripts on your filesystem are
> somehow shutting down
> the ethernet interface? Might be worth checking on a fresh filesystem.

I'm pretty sure that its not a problem with the filesystem. I'm using
exactly this filesystem for multiple other ARM based boards as well.
And all other boards (most of them with buildin ethernet controller
instead of USB connected) have no problem mounting/booting from it.

BTW: The filesystem is from the ELDK 5.3 [1][2]. You could download/install
it yourself.

>From your log I can see, that you are using a slightly different board
than I am ("Beagle xM Rev C" vs. "Beagle Rev C1/C2/C3"). So its a
different OMAP variant. Could this perhaps make a difference? Do you
by chance have the "old" Beagleboard (non-xM) at hand for another test?

Thanks again,
Stefan

[1] http://www.denx.de/wiki/view/ELDK-5/WebHome#Section_1.6.
[2] ftp://ftp.denx.de/pub/eldk/5.3/targets/armv7a/core-image-sato-sdk-generic-armv7a.tar.gz

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Stefan Roese]

Hi Roger,

On 07/11/2013 12:24 PM, Roger Quadros wrote:
> Stefan,
> 
> I tried it out today and it worked 5/5 times. I used a bare bones
> debian root filesystem for
> the NFS root.

Thanks for testing.

> Could it be possible that the boot scripts on your filesystem are
> somehow shutting down
> the ethernet interface? Might be worth checking on a fresh filesystem.

I'm pretty sure that its not a problem with the filesystem. I'm using
exactly this filesystem for multiple other ARM based boards as well.
And all other boards (most of them with buildin ethernet controller
instead of USB connected) have no problem mounting/booting from it.

BTW: The filesystem is from the ELDK 5.3 [1][2]. You could download/install
it yourself.

>From your log I can see, that you are using a slightly different board
than I am ("Beagle xM Rev C" vs. "Beagle Rev C1/C2/C3"). So its a
different OMAP variant. Could this perhaps make a difference? Do you
by chance have the "old" Beagleboard (non-xM) at hand for another test?

Thanks again,
Stefan

[1] http://www.denx.de/wiki/view/ELDK-5/WebHome#Section_1.6.
[2] ftp://ftp.denx.de/pub/eldk/5.3/targets/armv7a/core-image-sato-sdk-generic-armv7a.tar.gz

Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

On 07/11/2013 01:45 PM, Stefan Roese wrote:
> Hi Roger,
> 
> On 07/11/2013 12:24 PM, Roger Quadros wrote:
>> Stefan,
>>
>> I tried it out today and it worked 5/5 times. I used a bare bones
>> debian root filesystem for
>> the NFS root.
> 
> Thanks for testing.
> 
>> Could it be possible that the boot scripts on your filesystem are
>> somehow shutting down
>> the ethernet interface? Might be worth checking on a fresh filesystem.
> 
> I'm pretty sure that its not a problem with the filesystem. I'm using
> exactly this filesystem for multiple other ARM based boards as well.
> And all other boards (most of them with buildin ethernet controller
> instead of USB connected) have no problem mounting/booting from it.

OK, then it might be something to do with beagle.
Is pandaboard working fine for you?

> 
> BTW: The filesystem is from the ELDK 5.3 [1][2]. You could download/install
> it yourself.

OK. Will give it a try.
> 
> From your log I can see, that you are using a slightly different board
> than I am ("Beagle xM Rev C" vs. "Beagle Rev C1/C2/C3"). So its a

My board is a C2.

> different OMAP variant. Could this perhaps make a difference? Do you
> by chance have the "old" Beagleboard (non-xM) at hand for another test?

Sure. I have the old beagleboard with me. Let me know what to test.

cheers,
-roger

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

On 07/11/2013 01:45 PM, Stefan Roese wrote:
> Hi Roger,
> 
> On 07/11/2013 12:24 PM, Roger Quadros wrote:
>> Stefan,
>>
>> I tried it out today and it worked 5/5 times. I used a bare bones
>> debian root filesystem for
>> the NFS root.
> 
> Thanks for testing.
> 
>> Could it be possible that the boot scripts on your filesystem are
>> somehow shutting down
>> the ethernet interface? Might be worth checking on a fresh filesystem.
> 
> I'm pretty sure that its not a problem with the filesystem. I'm using
> exactly this filesystem for multiple other ARM based boards as well.
> And all other boards (most of them with buildin ethernet controller
> instead of USB connected) have no problem mounting/booting from it.

OK, then it might be something to do with beagle.
Is pandaboard working fine for you?

> 
> BTW: The filesystem is from the ELDK 5.3 [1][2]. You could download/install
> it yourself.

OK. Will give it a try.
> 
> From your log I can see, that you are using a slightly different board
> than I am ("Beagle xM Rev C" vs. "Beagle Rev C1/C2/C3"). So its a

My board is a C2.

> different OMAP variant. Could this perhaps make a difference? Do you
> by chance have the "old" Beagleboard (non-xM) at hand for another test?

Sure. I have the old beagleboard with me. Let me know what to test.

cheers,
-roger

Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Stefan Roese]

On 07/11/2013 02:00 PM, Roger Quadros wrote:
>>> Could it be possible that the boot scripts on your filesystem are
>>> somehow shutting down
>>> the ethernet interface? Might be worth checking on a fresh filesystem.
>>
>> I'm pretty sure that its not a problem with the filesystem. I'm using
>> exactly this filesystem for multiple other ARM based boards as well.
>> And all other boards (most of them with buildin ethernet controller
>> instead of USB connected) have no problem mounting/booting from it.
> 
> OK, then it might be something to do with beagle.
> Is pandaboard working fine for you?

I don't have a pandaboard here. Sorry. Only a another OMAP3530-based
board which also fails to boot via NFS.

>> BTW: The filesystem is from the ELDK 5.3 [1][2]. You could download/install
>> it yourself.
> 
> OK. Will give it a try.
>>
>> From your log I can see, that you are using a slightly different board
>> than I am ("Beagle xM Rev C" vs. "Beagle Rev C1/C2/C3"). So its a
> 
> My board is a C2.

Mine too.

>> different OMAP variant. Could this perhaps make a difference? Do you
>> by chance have the "old" Beagleboard (non-xM) at hand for another test?
> 
> Sure. I have the old beagleboard with me. Let me know what to test.

Either your debian rootfs via NFS or the ELDK one. As you have done with
the Beagle-xM. And then please repeat the NFS booting (if successful)
again for at least 5 times. Or even better, setup the bootcmd to
autoboot via NFS and tune your NFS rootfs to reboot automatically. So a
hangup in NFS booting would be noticed after some time with this board
automatically rebooting.

Thanks,
Stefan

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Stefan Roese]

On 07/11/2013 02:00 PM, Roger Quadros wrote:
>>> Could it be possible that the boot scripts on your filesystem are
>>> somehow shutting down
>>> the ethernet interface? Might be worth checking on a fresh filesystem.
>>
>> I'm pretty sure that its not a problem with the filesystem. I'm using
>> exactly this filesystem for multiple other ARM based boards as well.
>> And all other boards (most of them with buildin ethernet controller
>> instead of USB connected) have no problem mounting/booting from it.
> 
> OK, then it might be something to do with beagle.
> Is pandaboard working fine for you?

I don't have a pandaboard here. Sorry. Only a another OMAP3530-based
board which also fails to boot via NFS.

>> BTW: The filesystem is from the ELDK 5.3 [1][2]. You could download/install
>> it yourself.
> 
> OK. Will give it a try.
>>
>> From your log I can see, that you are using a slightly different board
>> than I am ("Beagle xM Rev C" vs. "Beagle Rev C1/C2/C3"). So its a
> 
> My board is a C2.

Mine too.

>> different OMAP variant. Could this perhaps make a difference? Do you
>> by chance have the "old" Beagleboard (non-xM) at hand for another test?
> 
> Sure. I have the old beagleboard with me. Let me know what to test.

Either your debian rootfs via NFS or the ELDK one. As you have done with
the Beagle-xM. And then please repeat the NFS booting (if successful)
again for at least 5 times. Or even better, setup the bootcmd to
autoboot via NFS and tune your NFS rootfs to reboot automatically. So a
hangup in NFS booting would be noticed after some time with this board
automatically rebooting.

Thanks,
Stefan

Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Stefan Roese]

On 07/11/2013 12:24 PM, Roger Quadros wrote:
> My u-boot script is below and boot log is attached.

BTW: I noticed a git ID (8e1cacd) in your kernel that I can't identify.
Do you have any patches locally applied to the kernel.org version that
might be helpful with this USB issue I'm seeing?

Thanks,
Stefan

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Stefan Roese]

On 07/11/2013 12:24 PM, Roger Quadros wrote:
> My u-boot script is below and boot log is attached.

BTW: I noticed a git ID (8e1cacd) in your kernel that I can't identify.
Do you have any patches locally applied to the kernel.org version that
might be helpful with this USB issue I'm seeing?

Thanks,
Stefan

Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

On 07/11/2013 03:41 PM, Stefan Roese wrote:
> On 07/11/2013 12:24 PM, Roger Quadros wrote:
>> My u-boot script is below and boot log is attached.
> 
> BTW: I noticed a git ID (8e1cacd) in your kernel that I can't identify.
> Do you have any patches locally applied to the kernel.org version that
> might be helpful with this USB issue I'm seeing?

Yes I had tested it on a more recent kernel with some local patches applied
that I've recently sent for review.

But to cross check with your setup I've retested it with commit d2b4a646 
with the 2 below patches on top

https://lkml.org/lkml/2013/6/20/327
https://lkml.org/lkml/2013/6/20/339

I've tried it again with the ELDK 5.3 root but still can't get it to fail.

I think we should match our u-boot as well. Could you please let me know
your u-boot commit and uEnv.txt?

My network setup is pretty simple, beagle-xm is connected directly to my laptop's
ethernet port. No network switch in between.

When you get the problem do you cold boot the board or warm boot it?
I've been always cold booting it.

cheers,
-roger

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

On 07/11/2013 03:41 PM, Stefan Roese wrote:
> On 07/11/2013 12:24 PM, Roger Quadros wrote:
>> My u-boot script is below and boot log is attached.
> 
> BTW: I noticed a git ID (8e1cacd) in your kernel that I can't identify.
> Do you have any patches locally applied to the kernel.org version that
> might be helpful with this USB issue I'm seeing?

Yes I had tested it on a more recent kernel with some local patches applied
that I've recently sent for review.

But to cross check with your setup I've retested it with commit d2b4a646 
with the 2 below patches on top

https://lkml.org/lkml/2013/6/20/327
https://lkml.org/lkml/2013/6/20/339

I've tried it again with the ELDK 5.3 root but still can't get it to fail.

I think we should match our u-boot as well. Could you please let me know
your u-boot commit and uEnv.txt?

My network setup is pretty simple, beagle-xm is connected directly to my laptop's
ethernet port. No network switch in between.

When you get the problem do you cold boot the board or warm boot it?
I've been always cold booting it.

cheers,
-roger

Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Stefan Roese]

On 07/11/2013 04:35 PM, Roger Quadros wrote:
>> BTW: I noticed a git ID (8e1cacd) in your kernel that I can't identify.
>> Do you have any patches locally applied to the kernel.org version that
>> might be helpful with this USB issue I'm seeing?
> 
> Yes I had tested it on a more recent kernel with some local patches applied
> that I've recently sent for review.
> 
> But to cross check with your setup I've retested it with commit d2b4a646 
> with the 2 below patches on top
> 
> https://lkml.org/lkml/2013/6/20/327
> https://lkml.org/lkml/2013/6/20/339

Thanks. I have exactly those 2 patches applies as well. But on a
different git commit. And with some local (unrelated) patches as well.
I'll revert to exactly your version tomorrow and test again.

> I've tried it again with the ELDK 5.3 root but still can't get it to fail.
> 
> I think we should match our u-boot as well. Could you please let me know
> your u-boot commit and uEnv.txt?

Good idea. I'm currently using a "dirty" local version. I'll try to
switch to an officially available version tomorrow. And send you the
version/git id.

> My network setup is pretty simple, beagle-xm is connected directly to my laptop's
> ethernet port. No network switch in between.

I have a switch in between the target and my PC. But this network setup
is also quite "simple" and works with all other boards as well. So this
shouldn't be a problem.

> When you get the problem do you cold boot the board or warm boot it?
> I've been always cold booting it.

I'm usually warm booting (pushbutton reset).

As mentioned above, I have some "homework" now to move to a
setup/configuration (official git commits) that you can reproduce on
your version C2 beagleboard as well. Stay tuned... ;)

Thanks,
Stefan

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Stefan Roese]

On 07/11/2013 04:35 PM, Roger Quadros wrote:
>> BTW: I noticed a git ID (8e1cacd) in your kernel that I can't identify.
>> Do you have any patches locally applied to the kernel.org version that
>> might be helpful with this USB issue I'm seeing?
> 
> Yes I had tested it on a more recent kernel with some local patches applied
> that I've recently sent for review.
> 
> But to cross check with your setup I've retested it with commit d2b4a646 
> with the 2 below patches on top
> 
> https://lkml.org/lkml/2013/6/20/327
> https://lkml.org/lkml/2013/6/20/339

Thanks. I have exactly those 2 patches applies as well. But on a
different git commit. And with some local (unrelated) patches as well.
I'll revert to exactly your version tomorrow and test again.

> I've tried it again with the ELDK 5.3 root but still can't get it to fail.
> 
> I think we should match our u-boot as well. Could you please let me know
> your u-boot commit and uEnv.txt?

Good idea. I'm currently using a "dirty" local version. I'll try to
switch to an officially available version tomorrow. And send you the
version/git id.

> My network setup is pretty simple, beagle-xm is connected directly to my laptop's
> ethernet port. No network switch in between.

I have a switch in between the target and my PC. But this network setup
is also quite "simple" and works with all other boards as well. So this
shouldn't be a problem.

> When you get the problem do you cold boot the board or warm boot it?
> I've been always cold booting it.

I'm usually warm booting (pushbutton reset).

As mentioned above, I have some "homework" now to move to a
setup/configuration (official git commits) that you can reproduce on
your version C2 beagleboard as well. Stay tuned... ;)

Thanks,
Stefan

Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

Stefan,

On 07/11/2013 08:52 PM, Stefan Roese wrote:
> On 07/11/2013 05:34 PM, Stefan Roese wrote:
>> On 07/11/2013 04:35 PM, Roger Quadros wrote:
>>>> BTW: I noticed a git ID (8e1cacd) in your kernel that I can't identify.
>>>> Do you have any patches locally applied to the kernel.org version that
>>>> might be helpful with this USB issue I'm seeing?
>>>
>>> Yes I had tested it on a more recent kernel with some local patches applied
>>> that I've recently sent for review.
>>>
>>> But to cross check with your setup I've retested it with commit d2b4a646 
>>> with the 2 below patches on top
>>>
>>> https://lkml.org/lkml/2013/6/20/327
>>> https://lkml.org/lkml/2013/6/20/339
>>
>> Thanks. I have exactly those 2 patches applies as well. But on a
>> different git commit. And with some local (unrelated) patches as well.
>> I'll revert to exactly your version tomorrow and test again.
> 
> Okay. I changed to exactly this version: d2b4a646 with those 2 patches
> on top.
> 
>>> I've tried it again with the ELDK 5.3 root but still can't get it to fail.
>>>
>>> I think we should match our u-boot as well. Could you please let me know
>>> your u-boot commit and uEnv.txt?
>>
>> Good idea. I'm currently using a "dirty" local version. I'll try to
>> switch to an officially available version tomorrow. And send you the
>> version/git id.
> 
> I updated my U-Boot to the following version: Based on mainline git
> commit ID 225fd8c. Only this patch added:
> 
> http://patchwork.ozlabs.org/patch/256702/
> 
> This is needed for USB to work in U-Boot. Otherwise my external USB
> SMSC95xx will not be detected in U-Boot.

I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
as I don't have an external USB-ethernet adapter.
The above commit doesn't work well for beagle-xm, so my u-boot is on tag v2013.04
and you don't need that additional patch.

Can you please retest on it? Thanks.

You will need to set "usbethaddr" before starting USB else SMSC will not work.
e.g.
	setenv usbethaddr A6:66:4D:B0:69:04

Also could you please increase the Linux console message verbosity to debug (8), so that
all kernel messages are visible in the log? If it spits out something more than what you
sent last time then do send it to me.

Let's first sort out the beagle-xm problem, then we can see about old beagle.

cheers,
-roger

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

Stefan,

On 07/11/2013 08:52 PM, Stefan Roese wrote:
> On 07/11/2013 05:34 PM, Stefan Roese wrote:
>> On 07/11/2013 04:35 PM, Roger Quadros wrote:
>>>> BTW: I noticed a git ID (8e1cacd) in your kernel that I can't identify.
>>>> Do you have any patches locally applied to the kernel.org version that
>>>> might be helpful with this USB issue I'm seeing?
>>>
>>> Yes I had tested it on a more recent kernel with some local patches applied
>>> that I've recently sent for review.
>>>
>>> But to cross check with your setup I've retested it with commit d2b4a646 
>>> with the 2 below patches on top
>>>
>>> https://lkml.org/lkml/2013/6/20/327
>>> https://lkml.org/lkml/2013/6/20/339
>>
>> Thanks. I have exactly those 2 patches applies as well. But on a
>> different git commit. And with some local (unrelated) patches as well.
>> I'll revert to exactly your version tomorrow and test again.
> 
> Okay. I changed to exactly this version: d2b4a646 with those 2 patches
> on top.
> 
>>> I've tried it again with the ELDK 5.3 root but still can't get it to fail.
>>>
>>> I think we should match our u-boot as well. Could you please let me know
>>> your u-boot commit and uEnv.txt?
>>
>> Good idea. I'm currently using a "dirty" local version. I'll try to
>> switch to an officially available version tomorrow. And send you the
>> version/git id.
> 
> I updated my U-Boot to the following version: Based on mainline git
> commit ID 225fd8c. Only this patch added:
> 
> http://patchwork.ozlabs.org/patch/256702/
> 
> This is needed for USB to work in U-Boot. Otherwise my external USB
> SMSC95xx will not be detected in U-Boot.

I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
as I don't have an external USB-ethernet adapter.
The above commit doesn't work well for beagle-xm, so my u-boot is on tag v2013.04
and you don't need that additional patch.

Can you please retest on it? Thanks.

You will need to set "usbethaddr" before starting USB else SMSC will not work.
e.g.
	setenv usbethaddr A6:66:4D:B0:69:04

Also could you please increase the Linux console message verbosity to debug (8), so that
all kernel messages are visible in the log? If it spits out something more than what you
sent last time then do send it to me.

Let's first sort out the beagle-xm problem, then we can see about old beagle.

cheers,
-roger

Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Stefan Roese]

Roger,

On 07/12/2013 11:15 AM, Roger Quadros wrote:
>>> Good idea. I'm currently using a "dirty" local version. I'll try to
>>> switch to an officially available version tomorrow. And send you the
>>> version/git id.
>>
>> I updated my U-Boot to the following version: Based on mainline git
>> commit ID 225fd8c. Only this patch added:
>>
>> http://patchwork.ozlabs.org/patch/256702/
>>
>> This is needed for USB to work in U-Boot. Otherwise my external USB
>> SMSC95xx will not be detected in U-Boot.
> 
> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
> as I don't have an external USB-ethernet adapter.

Too bad. This difference in boards makes the tests a bit less
meaningful. Is there really no USB-ethernet adapter somewhere in your
department (perhaps a non-SMSC95xx might serve as well?)? I might
send/order you one if necessary. ;)

> The above commit doesn't work well for beagle-xm,

Why is this? What does happen? Does U-Boot not boot up to the prompt?
Please send me a log.

> so my u-boot is on tag v2013.04
> and you don't need that additional patch.
> 
> Can you please retest on it? Thanks.

Done, please see below.

> You will need to set "usbethaddr" before starting USB else SMSC will not work.
> e.g.
> 	setenv usbethaddr A6:66:4D:B0:69:04

I don't have a beagle-xm, only my beable. And my U-Boot network setup is
already working, thanks.

> Also could you please increase the Linux console message verbosity to debug (8), so that
> all kernel messages are visible in the log? If it spits out something more than what you
> sent last time then do send it to me.

I added "ignore_loglevel" to the cmdline. But I cannot see anything
interesting that has not been there before with "debug" as well.

> Let's first sort out the beagle-xm problem, then we can see about old beagle.

Okay, I tested again with U-Boot v2013.01 plus my SMSC patch. Same
problem. NFS booting/mounting hangs at some time.

Thanks,
Stefan

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Stefan Roese]

Roger,

On 07/12/2013 11:15 AM, Roger Quadros wrote:
>>> Good idea. I'm currently using a "dirty" local version. I'll try to
>>> switch to an officially available version tomorrow. And send you the
>>> version/git id.
>>
>> I updated my U-Boot to the following version: Based on mainline git
>> commit ID 225fd8c. Only this patch added:
>>
>> http://patchwork.ozlabs.org/patch/256702/
>>
>> This is needed for USB to work in U-Boot. Otherwise my external USB
>> SMSC95xx will not be detected in U-Boot.
> 
> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
> as I don't have an external USB-ethernet adapter.

Too bad. This difference in boards makes the tests a bit less
meaningful. Is there really no USB-ethernet adapter somewhere in your
department (perhaps a non-SMSC95xx might serve as well?)? I might
send/order you one if necessary. ;)

> The above commit doesn't work well for beagle-xm,

Why is this? What does happen? Does U-Boot not boot up to the prompt?
Please send me a log.

> so my u-boot is on tag v2013.04
> and you don't need that additional patch.
> 
> Can you please retest on it? Thanks.

Done, please see below.

> You will need to set "usbethaddr" before starting USB else SMSC will not work.
> e.g.
> 	setenv usbethaddr A6:66:4D:B0:69:04

I don't have a beagle-xm, only my beable. And my U-Boot network setup is
already working, thanks.

> Also could you please increase the Linux console message verbosity to debug (8), so that
> all kernel messages are visible in the log? If it spits out something more than what you
> sent last time then do send it to me.

I added "ignore_loglevel" to the cmdline. But I cannot see anything
interesting that has not been there before with "debug" as well.

> Let's first sort out the beagle-xm problem, then we can see about old beagle.

Okay, I tested again with U-Boot v2013.01 plus my SMSC patch. Same
problem. NFS booting/mounting hangs at some time.

Thanks,
Stefan

Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

On 07/12/2013 01:52 PM, Stefan Roese wrote:
> Roger,
> 
> On 07/12/2013 11:15 AM, Roger Quadros wrote:
>>>> Good idea. I'm currently using a "dirty" local version. I'll try to
>>>> switch to an officially available version tomorrow. And send you the
>>>> version/git id.
>>>
>>> I updated my U-Boot to the following version: Based on mainline git
>>> commit ID 225fd8c. Only this patch added:
>>>
>>> http://patchwork.ozlabs.org/patch/256702/
>>>
>>> This is needed for USB to work in U-Boot. Otherwise my external USB
>>> SMSC95xx will not be detected in U-Boot.
>>
>> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
>> as I don't have an external USB-ethernet adapter.
> 
> Too bad. This difference in boards makes the tests a bit less
> meaningful. Is there really no USB-ethernet adapter somewhere in your
> department (perhaps a non-SMSC95xx might serve as well?)? I might
> send/order you one if necessary. ;)

Thanks for the offer :). I'll just get one for myself by today/tomorrow.
The one available here uses this driver "drivers/net/usb/asix.c"

> 
>> The above commit doesn't work well for beagle-xm,
> 
> Why is this? What does happen? Does U-Boot not boot up to the prompt?
> Please send me a log.

The last time it had failed I remember seeing a lot of IO pad configuration errors.
But I'm no longer able to reproduce that problem. Maybe it was just a messed up
build. In case I observe it again I'll let you know.

> 
>> so my u-boot is on tag v2013.04
>> and you don't need that additional patch.
>>
>> Can you please retest on it? Thanks.
> 
> Done, please see below.
> 
>> You will need to set "usbethaddr" before starting USB else SMSC will not work.
>> e.g.
>> 	setenv usbethaddr A6:66:4D:B0:69:04
> 
> I don't have a beagle-xm, only my beable. And my U-Boot network setup is
> already working, thanks.

Right. you won't need that for beagle. It was only for beagle-xm or panda with on board
usb-ethernet.

> 
>> Also could you please increase the Linux console message verbosity to debug (8), so that
>> all kernel messages are visible in the log? If it spits out something more than what you
>> sent last time then do send it to me.
> 
> I added "ignore_loglevel" to the cmdline. But I cannot see anything
> interesting that has not been there before with "debug" as well.

OK.

cheers,
-roger

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

On 07/12/2013 01:52 PM, Stefan Roese wrote:
> Roger,
> 
> On 07/12/2013 11:15 AM, Roger Quadros wrote:
>>>> Good idea. I'm currently using a "dirty" local version. I'll try to
>>>> switch to an officially available version tomorrow. And send you the
>>>> version/git id.
>>>
>>> I updated my U-Boot to the following version: Based on mainline git
>>> commit ID 225fd8c. Only this patch added:
>>>
>>> http://patchwork.ozlabs.org/patch/256702/
>>>
>>> This is needed for USB to work in U-Boot. Otherwise my external USB
>>> SMSC95xx will not be detected in U-Boot.
>>
>> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
>> as I don't have an external USB-ethernet adapter.
> 
> Too bad. This difference in boards makes the tests a bit less
> meaningful. Is there really no USB-ethernet adapter somewhere in your
> department (perhaps a non-SMSC95xx might serve as well?)? I might
> send/order you one if necessary. ;)

Thanks for the offer :). I'll just get one for myself by today/tomorrow.
The one available here uses this driver "drivers/net/usb/asix.c"

> 
>> The above commit doesn't work well for beagle-xm,
> 
> Why is this? What does happen? Does U-Boot not boot up to the prompt?
> Please send me a log.

The last time it had failed I remember seeing a lot of IO pad configuration errors.
But I'm no longer able to reproduce that problem. Maybe it was just a messed up
build. In case I observe it again I'll let you know.

> 
>> so my u-boot is on tag v2013.04
>> and you don't need that additional patch.
>>
>> Can you please retest on it? Thanks.
> 
> Done, please see below.
> 
>> You will need to set "usbethaddr" before starting USB else SMSC will not work.
>> e.g.
>> 	setenv usbethaddr A6:66:4D:B0:69:04
> 
> I don't have a beagle-xm, only my beable. And my U-Boot network setup is
> already working, thanks.

Right. you won't need that for beagle. It was only for beagle-xm or panda with on board
usb-ethernet.

> 
>> Also could you please increase the Linux console message verbosity to debug (8), so that
>> all kernel messages are visible in the log? If it spits out something more than what you
>> sent last time then do send it to me.
> 
> I added "ignore_loglevel" to the cmdline. But I cannot see anything
> interesting that has not been there before with "debug" as well.

OK.

cheers,
-roger

Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Stefan Roese]

On 07/15/2013 10:16 AM, Roger Quadros wrote:
>>> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
>>> as I don't have an external USB-ethernet adapter.
>>
>> Too bad. This difference in boards makes the tests a bit less
>> meaningful. Is there really no USB-ethernet adapter somewhere in your
>> department (perhaps a non-SMSC95xx might serve as well?)? I might
>> send/order you one if necessary. ;)
> 
> Thanks for the offer :). I'll just get one for myself by today/tomorrow.
> The one available here uses this driver "drivers/net/usb/asix.c"

Great.

>>
>>> The above commit doesn't work well for beagle-xm,
>>
>> Why is this? What does happen? Does U-Boot not boot up to the prompt?
>> Please send me a log.
> 
> The last time it had failed I remember seeing a lot of IO pad configuration errors.
> But I'm no longer able to reproduce that problem. Maybe it was just a messed up
> build. In case I observe it again I'll let you know.

It might be related to a problem with the gd (global-data) pointer being
overwritten in den SPL. This is still not finally resolved the upcoming
release:

http://patchwork.ozlabs.org/patch/251293/

>>
>>> so my u-boot is on tag v2013.04
>>> and you don't need that additional patch.
>>>
>>> Can you please retest on it? Thanks.
>>
>> Done, please see below.
>>
>>> You will need to set "usbethaddr" before starting USB else SMSC will not work.
>>> e.g.
>>> 	setenv usbethaddr A6:66:4D:B0:69:04
>>
>> I don't have a beagle-xm, only my beable. And my U-Boot network setup is
>> already working, thanks.
> 
> Right. you won't need that for beagle. It was only for beagle-xm or panda with on board
> usb-ethernet.

I'm using the (external) USB-ethernet adapter on the beagle in U-Boot as
well. To tftp the kernel/dtb.

Thanks,
Stefan

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Stefan Roese]

On 07/15/2013 10:16 AM, Roger Quadros wrote:
>>> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
>>> as I don't have an external USB-ethernet adapter.
>>
>> Too bad. This difference in boards makes the tests a bit less
>> meaningful. Is there really no USB-ethernet adapter somewhere in your
>> department (perhaps a non-SMSC95xx might serve as well?)? I might
>> send/order you one if necessary. ;)
> 
> Thanks for the offer :). I'll just get one for myself by today/tomorrow.
> The one available here uses this driver "drivers/net/usb/asix.c"

Great.

>>
>>> The above commit doesn't work well for beagle-xm,
>>
>> Why is this? What does happen? Does U-Boot not boot up to the prompt?
>> Please send me a log.
> 
> The last time it had failed I remember seeing a lot of IO pad configuration errors.
> But I'm no longer able to reproduce that problem. Maybe it was just a messed up
> build. In case I observe it again I'll let you know.

It might be related to a problem with the gd (global-data) pointer being
overwritten in den SPL. This is still not finally resolved the upcoming
release:

http://patchwork.ozlabs.org/patch/251293/

>>
>>> so my u-boot is on tag v2013.04
>>> and you don't need that additional patch.
>>>
>>> Can you please retest on it? Thanks.
>>
>> Done, please see below.
>>
>>> You will need to set "usbethaddr" before starting USB else SMSC will not work.
>>> e.g.
>>> 	setenv usbethaddr A6:66:4D:B0:69:04
>>
>> I don't have a beagle-xm, only my beable. And my U-Boot network setup is
>> already working, thanks.
> 
> Right. you won't need that for beagle. It was only for beagle-xm or panda with on board
> usb-ethernet.

I'm using the (external) USB-ethernet adapter on the beagle in U-Boot as
well. To tftp the kernel/dtb.

Thanks,
Stefan

Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

+Alan

On 07/15/2013 11:24 AM, Stefan Roese wrote:
> On 07/15/2013 10:16 AM, Roger Quadros wrote:
>>>> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
>>>> as I don't have an external USB-ethernet adapter.
>>>
>>> Too bad. This difference in boards makes the tests a bit less
>>> meaningful. Is there really no USB-ethernet adapter somewhere in your
>>> department (perhaps a non-SMSC95xx might serve as well?)? I might
>>> send/order you one if necessary. ;)
>>
>> Thanks for the offer :). I'll just get one for myself by today/tomorrow.
>> The one available here uses this driver "drivers/net/usb/asix.c"
> 
> Great.
> 

OK. Finally managed to reproduce the problem.

Don't know the root cause yet. Will need to investigate.

[   92.054138] ------------[ cut here ]------------
[   92.059082] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x278/0x29c()
[   92.066741] NETDEV WATCHDOG: eth0 (asix): transmit queue 0 timed out
[   92.073425] Modules linked in:
[   92.076721] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-06007-g83bebb4 #837
[   92.084594] [<c001b868>] (unwind_backtrace+0x0/0xf0) from [<c0017bbc>] (show_stack+0x10/0x14)
[   92.093597] [<c0017bbc>] (show_stack+0x10/0x14) from [<c04f7658>] (dump_stack+0x78/0x94)
[   92.102172] [<c04f7658>] (dump_stack+0x78/0x94) from [<c00440b8>] (warn_slowpath_common+0x4c/0x6c)
[   92.111694] [<c00440b8>] (warn_slowpath_common+0x4c/0x6c) from [<c004416c>] (warn_slowpath_fmt+0x30/0x40)
[   92.121826] [<c004416c>] (warn_slowpath_fmt+0x30/0x40) from [<c045aa28>] (dev_watchdog+0x278/0x29c)
[   92.131439] [<c045aa28>] (dev_watchdog+0x278/0x29c) from [<c0052d0c>] (call_timer_fn+0x80/0x168)
[   92.140747] [<c0052d0c>] (call_timer_fn+0x80/0x168) from [<c0052f98>] (run_timer_softirq+0x1a4/0x290)
[   92.150512] [<c0052f98>] (run_timer_softirq+0x1a4/0x290) from [<c004bddc>] (__do_softirq+0x100/0x27c)
[   92.160308] [<c004bddc>] (__do_softirq+0x100/0x27c) from [<c004c2fc>] (irq_exit+0xa0/0xdc)
[   92.169067] [<c004c2fc>] (irq_exit+0xa0/0xdc) from [<c0014ccc>] (handle_IRQ+0x50/0xb0)
[   92.177490] [<c0014ccc>] (handle_IRQ+0x50/0xb0) from [<c000862c>] (omap3_intc_handle_irq+0x60/0x74)
[   92.187072] [<c000862c>] (omap3_intc_handle_irq+0x60/0x74) from [<c04fd5a4>] (__irq_svc+0x44/0x5c)
[   92.196563] Exception stack(0xc0775f58 to 0xc0775fa0)
[   92.201873] 5f40:                                                       00000001 00000001
[   92.210540] 5f60: 00000000 c077fd08 c0774000 00000000 c080acc0 c080a5ee c080acc0 c0509860
[   92.219207] 5f80: c077c9a8 c0774000 ce0ce578 c0775fa0 c0097b18 c0015034 200f0013 ffffffff
[   92.227874] [<c04fd5a4>] (__irq_svc+0x44/0x5c) from [<c0015034>] (arch_cpu_idle+0x20/0x3c)
[   92.236663] [<c0015034>] (arch_cpu_idle+0x20/0x3c) from [<c0086268>] (cpu_startup_entry+0x80/0x21c)
[   92.246276] [<c0086268>] (cpu_startup_entry+0x80/0x21c) from [<c0714820>] (start_kernel+0x2c4/0x320)
[   92.255950] ---[ end trace 29c2af54cf6c8fa8 ]---
[   92.272674] ehci-omap 48064800.ehci: IAA watchdog: status e008 cmd 10075
[   92.291137] ehci-omap 48064800.ehci: IAA watchdog: status e008 cmd 10075

cheers,
-roger

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

+Alan

On 07/15/2013 11:24 AM, Stefan Roese wrote:
> On 07/15/2013 10:16 AM, Roger Quadros wrote:
>>>> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
>>>> as I don't have an external USB-ethernet adapter.
>>>
>>> Too bad. This difference in boards makes the tests a bit less
>>> meaningful. Is there really no USB-ethernet adapter somewhere in your
>>> department (perhaps a non-SMSC95xx might serve as well?)? I might
>>> send/order you one if necessary. ;)
>>
>> Thanks for the offer :). I'll just get one for myself by today/tomorrow.
>> The one available here uses this driver "drivers/net/usb/asix.c"
> 
> Great.
> 

OK. Finally managed to reproduce the problem.

Don't know the root cause yet. Will need to investigate.

[   92.054138] ------------[ cut here ]------------
[   92.059082] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x278/0x29c()
[   92.066741] NETDEV WATCHDOG: eth0 (asix): transmit queue 0 timed out
[   92.073425] Modules linked in:
[   92.076721] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-06007-g83bebb4 #837
[   92.084594] [<c001b868>] (unwind_backtrace+0x0/0xf0) from [<c0017bbc>] (show_stack+0x10/0x14)
[   92.093597] [<c0017bbc>] (show_stack+0x10/0x14) from [<c04f7658>] (dump_stack+0x78/0x94)
[   92.102172] [<c04f7658>] (dump_stack+0x78/0x94) from [<c00440b8>] (warn_slowpath_common+0x4c/0x6c)
[   92.111694] [<c00440b8>] (warn_slowpath_common+0x4c/0x6c) from [<c004416c>] (warn_slowpath_fmt+0x30/0x40)
[   92.121826] [<c004416c>] (warn_slowpath_fmt+0x30/0x40) from [<c045aa28>] (dev_watchdog+0x278/0x29c)
[   92.131439] [<c045aa28>] (dev_watchdog+0x278/0x29c) from [<c0052d0c>] (call_timer_fn+0x80/0x168)
[   92.140747] [<c0052d0c>] (call_timer_fn+0x80/0x168) from [<c0052f98>] (run_timer_softirq+0x1a4/0x290)
[   92.150512] [<c0052f98>] (run_timer_softirq+0x1a4/0x290) from [<c004bddc>] (__do_softirq+0x100/0x27c)
[   92.160308] [<c004bddc>] (__do_softirq+0x100/0x27c) from [<c004c2fc>] (irq_exit+0xa0/0xdc)
[   92.169067] [<c004c2fc>] (irq_exit+0xa0/0xdc) from [<c0014ccc>] (handle_IRQ+0x50/0xb0)
[   92.177490] [<c0014ccc>] (handle_IRQ+0x50/0xb0) from [<c000862c>] (omap3_intc_handle_irq+0x60/0x74)
[   92.187072] [<c000862c>] (omap3_intc_handle_irq+0x60/0x74) from [<c04fd5a4>] (__irq_svc+0x44/0x5c)
[   92.196563] Exception stack(0xc0775f58 to 0xc0775fa0)
[   92.201873] 5f40:                                                       00000001 00000001
[   92.210540] 5f60: 00000000 c077fd08 c0774000 00000000 c080acc0 c080a5ee c080acc0 c0509860
[   92.219207] 5f80: c077c9a8 c0774000 ce0ce578 c0775fa0 c0097b18 c0015034 200f0013 ffffffff
[   92.227874] [<c04fd5a4>] (__irq_svc+0x44/0x5c) from [<c0015034>] (arch_cpu_idle+0x20/0x3c)
[   92.236663] [<c0015034>] (arch_cpu_idle+0x20/0x3c) from [<c0086268>] (cpu_startup_entry+0x80/0x21c)
[   92.246276] [<c0086268>] (cpu_startup_entry+0x80/0x21c) from [<c0714820>] (start_kernel+0x2c4/0x320)
[   92.255950] ---[ end trace 29c2af54cf6c8fa8 ]---
[   92.272674] ehci-omap 48064800.ehci: IAA watchdog: status e008 cmd 10075
[   92.291137] ehci-omap 48064800.ehci: IAA watchdog: status e008 cmd 10075

cheers,
-roger

Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Stefan Roese]

Hi Roger,

On 07/16/2013 04:37 PM, Roger Quadros wrote:
> On 07/15/2013 11:24 AM, Stefan Roese wrote:
>> On 07/15/2013 10:16 AM, Roger Quadros wrote:
>>>>> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
>>>>> as I don't have an external USB-ethernet adapter.
>>>>
>>>> Too bad. This difference in boards makes the tests a bit less
>>>> meaningful. Is there really no USB-ethernet adapter somewhere in your
>>>> department (perhaps a non-SMSC95xx might serve as well?)? I might
>>>> send/order you one if necessary. ;)
>>>
>>> Thanks for the offer :). I'll just get one for myself by today/tomorrow.
>>> The one available here uses this driver "drivers/net/usb/asix.c"
>>
>> Great.
>>
> 
> OK. Finally managed to reproduce the problem.

Ahh, great. Thanks for the effort.

> Don't know the root cause yet. Will need to investigate.

Thanks. Just let me know if I can be of any assistance (testing etc).

Cheers,
Stefan

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Stefan Roese]

Hi Roger,

On 07/16/2013 04:37 PM, Roger Quadros wrote:
> On 07/15/2013 11:24 AM, Stefan Roese wrote:
>> On 07/15/2013 10:16 AM, Roger Quadros wrote:
>>>>> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
>>>>> as I don't have an external USB-ethernet adapter.
>>>>
>>>> Too bad. This difference in boards makes the tests a bit less
>>>> meaningful. Is there really no USB-ethernet adapter somewhere in your
>>>> department (perhaps a non-SMSC95xx might serve as well?)? I might
>>>> send/order you one if necessary. ;)
>>>
>>> Thanks for the offer :). I'll just get one for myself by today/tomorrow.
>>> The one available here uses this driver "drivers/net/usb/asix.c"
>>
>> Great.
>>
> 
> OK. Finally managed to reproduce the problem.

Ahh, great. Thanks for the effort.

> Don't know the root cause yet. Will need to investigate.

Thanks. Just let me know if I can be of any assistance (testing etc).

Cheers,
Stefan

Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

On 07/16/2013 07:19 PM, Stefan Roese wrote:
> Hi Roger,
> 
> On 07/16/2013 04:37 PM, Roger Quadros wrote:
>> On 07/15/2013 11:24 AM, Stefan Roese wrote:
>>> On 07/15/2013 10:16 AM, Roger Quadros wrote:
>>>>>> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
>>>>>> as I don't have an external USB-ethernet adapter.
>>>>>
>>>>> Too bad. This difference in boards makes the tests a bit less
>>>>> meaningful. Is there really no USB-ethernet adapter somewhere in your
>>>>> department (perhaps a non-SMSC95xx might serve as well?)? I might
>>>>> send/order you one if necessary. ;)
>>>>
>>>> Thanks for the offer :). I'll just get one for myself by today/tomorrow.
>>>> The one available here uses this driver "drivers/net/usb/asix.c"
>>>
>>> Great.
>>>
>>
>> OK. Finally managed to reproduce the problem.
> 
> Ahh, great. Thanks for the effort.
> 
>> Don't know the root cause yet. Will need to investigate.
> 
> Thanks. Just let me know if I can be of any assistance (testing etc).
> 

For the record, not resetting the OMAP USB Host Module (UHH) from u-boot seems to solve
the issue.

Patch for u-boot below.

From: Roger Quadros <rogerq@ti.com>
Date: Fri, 19 Jul 2013 15:26:14 +0300
Subject: [PATCH] usb: ehci-omap: Don't softreset USB High-speed Host (UHH) Module

Fixes NFS root problems with Beagle (3530 ES1.0) when used with
external USB-ethernet adapter and "USB start" command used within
u-boot.

Soft resetting the UHH module causes instability issues on
all OMAPs so we just avoid it.

See OMAP36xx Errata
  i571: USB host EHCI may stall when entering smart-standby mode
  i660: USBHOST Configured In Smart-Idle Can Lead To a Deadlock

On OMAP4/5, soft-resetting the UHH module can put it into
Smart-Idle mode and lead to a deadlock.

On OMAP3 this doesn't seem to be the case but still instabilities
are observed on beagle (3530 ES1.0) if soft-reset is used.
 e.g. NFS root failures with Linux kernel.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 drivers/usb/host/ehci-omap.c |   17 +++++++++++++++++
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 086c697..628e86c 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -42,6 +42,22 @@ static struct omap_ehci *const ehci = (struct omap_ehci *)OMAP_EHCI_BASE;
 
 static int omap_uhh_reset(void)
 {
+/*
+ * Soft resetting the UHH module causes instability issues on
+ * all OMAPs so we just avoid it.
+ *
+ * See OMAP36xx Errata
+ *  i571: USB host EHCI may stall when entering smart-standby mode
+ *  i660: USBHOST Configured In Smart-Idle Can Lead To a Deadlock
+ *
+ * On OMAP4/5, soft-resetting the UHH module will put it into
+ * Smart-Idle mode and lead to a deadlock.
+ *
+ * On OMAP3 this doesn't seem to be the case but still instabilities
+ * are observed on beagle (3530 ES1.0) if soft-reset is used.
+ * e.g. NFS root failures with Linux kernel.
+ */
+#if 0
 	unsigned long init = get_timer(0);
 
 	/* perform UHH soft reset, and wait until reset is complete */
@@ -53,6 +69,7 @@ static int omap_uhh_reset(void)
 			debug("OMAP UHH error: timeout resetting ehci\n");
 			return -EL3RST;
 		}
+#endif
 
 	return 0;
 }
-- 
1.7.4.1

[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx

[Roger Quadros]

On 07/16/2013 07:19 PM, Stefan Roese wrote:
> Hi Roger,
> 
> On 07/16/2013 04:37 PM, Roger Quadros wrote:
>> On 07/15/2013 11:24 AM, Stefan Roese wrote:
>>> On 07/15/2013 10:16 AM, Roger Quadros wrote:
>>>>>> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
>>>>>> as I don't have an external USB-ethernet adapter.
>>>>>
>>>>> Too bad. This difference in boards makes the tests a bit less
>>>>> meaningful. Is there really no USB-ethernet adapter somewhere in your
>>>>> department (perhaps a non-SMSC95xx might serve as well?)? I might
>>>>> send/order you one if necessary. ;)
>>>>
>>>> Thanks for the offer :). I'll just get one for myself by today/tomorrow.
>>>> The one available here uses this driver "drivers/net/usb/asix.c"
>>>
>>> Great.
>>>
>>
>> OK. Finally managed to reproduce the problem.
> 
> Ahh, great. Thanks for the effort.
> 
>> Don't know the root cause yet. Will need to investigate.
> 
> Thanks. Just let me know if I can be of any assistance (testing etc).
> 

For the record, not resetting the OMAP USB Host Module (UHH) from u-boot seems to solve
the issue.

Patch for u-boot below.

From: Roger Quadros <rogerq@ti.com>
Date: Fri, 19 Jul 2013 15:26:14 +0300
Subject: [PATCH] usb: ehci-omap: Don't softreset USB High-speed Host (UHH) Module

Fixes NFS root problems with Beagle (3530 ES1.0) when used with
external USB-ethernet adapter and "USB start" command used within
u-boot.

Soft resetting the UHH module causes instability issues on
all OMAPs so we just avoid it.

See OMAP36xx Errata
  i571: USB host EHCI may stall when entering smart-standby mode
  i660: USBHOST Configured In Smart-Idle Can Lead To a Deadlock

On OMAP4/5, soft-resetting the UHH module can put it into
Smart-Idle mode and lead to a deadlock.

On OMAP3 this doesn't seem to be the case but still instabilities
are observed on beagle (3530 ES1.0) if soft-reset is used.
 e.g. NFS root failures with Linux kernel.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 drivers/usb/host/ehci-omap.c |   17 +++++++++++++++++
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 086c697..628e86c 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -42,6 +42,22 @@ static struct omap_ehci *const ehci = (struct omap_ehci *)OMAP_EHCI_BASE;
 
 static int omap_uhh_reset(void)
 {
+/*
+ * Soft resetting the UHH module causes instability issues on
+ * all OMAPs so we just avoid it.
+ *
+ * See OMAP36xx Errata
+ *  i571: USB host EHCI may stall when entering smart-standby mode
+ *  i660: USBHOST Configured In Smart-Idle Can Lead To a Deadlock
+ *
+ * On OMAP4/5, soft-resetting the UHH module will put it into
+ * Smart-Idle mode and lead to a deadlock.
+ *
+ * On OMAP3 this doesn't seem to be the case but still instabilities
+ * are observed on beagle (3530 ES1.0) if soft-reset is used.
+ * e.g. NFS root failures with Linux kernel.
+ */
+#if 0
 	unsigned long init = get_timer(0);
 
 	/* perform UHH soft reset, and wait until reset is complete */
@@ -53,6 +69,7 @@ static int omap_uhh_reset(void)
 			debug("OMAP UHH error: timeout resetting ehci\n");
 			return -EL3RST;
 		}
+#endif
 
 	return 0;
 }
-- 
1.7.4.1