Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
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 rog...@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 rog...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
+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: 0001 0001 [ 92.210540] 5f60: c077fd08 c0774000 c080acc0 c080a5ee c080acc0 c0509860 [ 92.219207] 5f80: c077c9a8 c0774000 ce0ce578 c0775fa0 c0097b18 c0015034 200f0013 [ 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
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 0x825f omap3-beagle.dtb tftpboot 0x8030 uImage set fdt_high 0x bootm 0x8030 - 0x825f cheers, -roger 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 #700a00229ff8016842c91300d00e Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 3 2 1 0 mmc0 is current device reading boot.scr 440 bytes read Running bootscript from mmc0 ... ## Executing script at 8200 (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: 0x825f Loading: *EHCI 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: 0x8030 Loading: *# # # # ### done Bytes transferred = 4088512 (3e62c0 hex) Unknown command 'set' - try 'help' ## Booting kernel from Legacy Image at 8030 ... 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 825f Booting using the fdt blob at 0x825f Loading Kernel Image ... OK OK Using Device Tree in place at 825f, end 825f6370 Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] 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.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic OMAP3 (Flattened Device Tree), model: TI OMAP3 BeagleBoard xM [0.00] cma: CMA: reserved 16 MiB at 9e80 [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] CPU: All CPU(s) started in SVC mode. [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) [0.00] PERCPU: Embedded 9 pages/cpu @c1188000 s14208 r8192 d14464 u36864 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129792 [0.00] Kernel command line: console=ttyO2,115200n8 root=/dev/nfs rw nfsroot=192.168.2.1:/srv/nfsroot/ ip=192.168.2.2 rootwait [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 488432K/523264K available (5305K kernel code, 611K rwdata, 1936K rodata, 381K init, 5522K bss, 34832K reserved, 0K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xe080 - 0xff00 ( 488 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
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 rog...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
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 rog...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
* Roger Quadros rog...@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 rog...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
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 rog...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
