| Message ID | 1366024808-4691-1-git-send-email-rogerq@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
+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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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:
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(-)