[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

[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

[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

[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]

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,
> 
>>
>> 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>

[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

[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

[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 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

[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

[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

[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

[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

[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

[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

[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

[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

[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