[U-Boot] Ethernet on PandaBoard
I just tried rev 211e47549b668c7cdd8658c0413a272f0d0495d4 (v2012.07-rc1) for my PandaBoard. Sadly, this is failing when I try to use the onboard ethernet (EHCI USB based) controller:
U-Boot SPL 2012.07-rc1 (Jul 11 2012 - 06:56:00) OMAP4430 ES2.2 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img
U-Boot 2012.07-rc1 (Jul 11 2012 - 06:56:00)
CPU : OMAP4430 ES2.2 Board: OMAP4 Panda I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0 Using default environment
In: serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 Panda # usb start (Re)start USB... USB: Register 1313 NbrPorts 3 data abort pc : [<bff9acb0>] lr : [<bff9ac91>] sp : bff08e28 ip : 0000000f fp : 00000000 r10: bff0a370 r9 : 00000002 r8 : bff08f68 r7 : bffbb070 r6 : 00000000 r5 : bffaee04 r4 : 00001313 r3 : bffaee04 r2 : 98000000 r1 : 0000000a r0 : 00000019 Flags: Nzcv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
Anyone else see this? Ideas?
How do I map these addresses (PC=0xbff9acb0) to the ones in my u-boot ELF image (so I can figure out what went wrong)?
Thanks
Hi Gray,
This wiki page might help you. http://www.denx.de/wiki/view/DULG/DecodingUBootCrashDumps
On 2012/07/11, at 22:08, Gary Thomas wrote:
I just tried rev 211e47549b668c7cdd8658c0413a272f0d0495d4 (v2012.07-rc1) for my PandaBoard. Sadly, this is failing when I try to use the onboard ethernet (EHCI USB based) controller:
U-Boot SPL 2012.07-rc1 (Jul 11 2012 - 06:56:00) OMAP4430 ES2.2 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img
U-Boot 2012.07-rc1 (Jul 11 2012 - 06:56:00)
CPU : OMAP4430 ES2.2 Board: OMAP4 Panda I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0 Using default environment
In: serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 Panda # usb start (Re)start USB... USB: Register 1313 NbrPorts 3 data abort pc : [<bff9acb0>] lr : [<bff9ac91>] sp : bff08e28 ip : 0000000f fp : 00000000 r10: bff0a370 r9 : 00000002 r8 : bff08f68 r7 : bffbb070 r6 : 00000000 r5 : bffaee04 r4 : 00001313 r3 : bffaee04 r2 : 98000000 r1 : 0000000a r0 : 00000019 Flags: Nzcv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
Anyone else see this? Ideas?
How do I map these addresses (PC=0xbff9acb0) to the ones in my u-boot ELF image (so I can figure out what went wrong)?
Thanks
On 2012-07-11 07:08, Gary Thomas wrote:
I just tried rev 211e47549b668c7cdd8658c0413a272f0d0495d4 (v2012.07-rc1) for my PandaBoard. Sadly, this is failing when I try to use the onboard ethernet (EHCI USB based) controller:
U-Boot SPL 2012.07-rc1 (Jul 11 2012 - 06:56:00) OMAP4430 ES2.2 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img
U-Boot 2012.07-rc1 (Jul 11 2012 - 06:56:00)
CPU : OMAP4430 ES2.2 Board: OMAP4 Panda I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0 Using default environment
In: serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 Panda # usb start (Re)start USB... USB: Register 1313 NbrPorts 3 data abort pc : [<bff9acb0>] lr : [<bff9ac91>] sp : bff08e28 ip : 0000000f fp : 00000000 r10: bff0a370 r9 : 00000002 r8 : bff08f68 r7 : bffbb070 r6 : 00000000 r5 : bffaee04 r4 : 00001313 r3 : bffaee04 r2 : 98000000 r1 : 0000000a r0 : 00000019 Flags: Nzcv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
Anyone else see this? Ideas?
How do I map these addresses (PC=0xbff9acb0) to the ones in my u-boot ELF image (so I can figure out what went wrong)?
Thanks
This turns out to be related to access to the wHubCharacteristics field in a hub descriptor. This field is u16, but not u16 aligned, hence the data abort.
Has something changed recently? I have a version of U-Boot built for this board based on 2011.06 from the meta-ti tree which does not suffer from these problems.
Hi Gray,
On 2012/07/12, at 0:13, Gary Thomas wrote:
On 2012-07-11 07:08, Gary Thomas wrote:
I just tried rev 211e47549b668c7cdd8658c0413a272f0d0495d4 (v2012.07-rc1) for my PandaBoard. Sadly, this is failing when I try to use the onboard ethernet (EHCI USB based) controller:
U-Boot SPL 2012.07-rc1 (Jul 11 2012 - 06:56:00) OMAP4430 ES2.2 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img
U-Boot 2012.07-rc1 (Jul 11 2012 - 06:56:00)
CPU : OMAP4430 ES2.2 Board: OMAP4 Panda I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0 Using default environment
In: serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 Panda # usb start (Re)start USB... USB: Register 1313 NbrPorts 3 data abort pc : [<bff9acb0>] lr : [<bff9ac91>] sp : bff08e28 ip : 0000000f fp : 00000000 r10: bff0a370 r9 : 00000002 r8 : bff08f68 r7 : bffbb070 r6 : 00000000 r5 : bffaee04 r4 : 00001313 r3 : bffaee04 r2 : 98000000 r1 : 0000000a r0 : 00000019 Flags: Nzcv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
Anyone else see this? Ideas?
How do I map these addresses (PC=0xbff9acb0) to the ones in my u-boot ELF image (so I can figure out what went wrong)?
Thanks
This turns out to be related to access to the wHubCharacteristics field in a hub descriptor. This field is u16, but not u16 aligned, hence the data abort.
Has something changed recently? I have a version of U-Boot built for this board based on 2011.06 from the meta-ti tree which does not suffer from these problems.
How about this patch?
[PATCH] arm: armv7: add compile option -mno-unaligned-access if available http://lists.denx.de/pipermail/u-boot/2012-July/127260.html
On 2012-07-11 09:32, Tetsuyuki Kobayashi wrote:
Hi Gray,
On 2012/07/12, at 0:13, Gary Thomas wrote:
On 2012-07-11 07:08, Gary Thomas wrote:
I just tried rev 211e47549b668c7cdd8658c0413a272f0d0495d4 (v2012.07-rc1) for my PandaBoard. Sadly, this is failing when I try to use the onboard ethernet (EHCI USB based) controller:
U-Boot SPL 2012.07-rc1 (Jul 11 2012 - 06:56:00) OMAP4430 ES2.2 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img
U-Boot 2012.07-rc1 (Jul 11 2012 - 06:56:00)
CPU : OMAP4430 ES2.2 Board: OMAP4 Panda I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0 Using default environment
In: serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 Panda # usb start (Re)start USB... USB: Register 1313 NbrPorts 3 data abort pc : [<bff9acb0>] lr : [<bff9ac91>] sp : bff08e28 ip : 0000000f fp : 00000000 r10: bff0a370 r9 : 00000002 r8 : bff08f68 r7 : bffbb070 r6 : 00000000 r5 : bffaee04 r4 : 00001313 r3 : bffaee04 r2 : 98000000 r1 : 0000000a r0 : 00000019 Flags: Nzcv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
Anyone else see this? Ideas?
How do I map these addresses (PC=0xbff9acb0) to the ones in my u-boot ELF image (so I can figure out what went wrong)?
Thanks
This turns out to be related to access to the wHubCharacteristics field in a hub descriptor. This field is u16, but not u16 aligned, hence the data abort.
Has something changed recently? I have a version of U-Boot built for this board based on 2011.06 from the meta-ti tree which does not suffer from these problems.
How about this patch?
[PATCH] arm: armv7: add compile option -mno-unaligned-access if available http://lists.denx.de/pipermail/u-boot/2012-July/127260.html
Cool! that fixed it - my network is working now.
On Wed, Jul 11, 2012 at 07:08:50AM -0600, Gary Thomas wrote:
I just tried rev 211e47549b668c7cdd8658c0413a272f0d0495d4 (v2012.07-rc1) for my PandaBoard. Sadly, this is failing when I try to use the onboard ethernet (EHCI USB based) controller:
Sorry for the late response, at a conference. This is a known problem and we will either have this fixed soon (Ilya Yanok is working on a series) or we will build-time disable dcache support on these boards and fix this properly for the next release.
In short, some cache clean-ups in ehci-hcd.c exposed other cache problems on other platforms where our cache size is 64 not 32bytes.
On Thu, Jul 12, 2012 at 02:20:18AM -0700, Tom Rini wrote:
On Wed, Jul 11, 2012 at 07:08:50AM -0600, Gary Thomas wrote:
I just tried rev 211e47549b668c7cdd8658c0413a272f0d0495d4 (v2012.07-rc1) for my PandaBoard. Sadly, this is failing when I try to use the onboard ethernet (EHCI USB based) controller:
Sorry for the late response, at a conference. This is a known problem and we will either have this fixed soon (Ilya Yanok is working on a series) or we will build-time disable dcache support on these boards and fix this properly for the next release.
In short, some cache clean-ups in ehci-hcd.c exposed other cache problems on other platforms where our cache size is 64 not 32bytes.
I take it back, I forgot omap4 is 32byte cache. With the fix that Tetsuyuki Kobayashi pointed you at (oh, and a Tested-by to that thread if you can), can you please do a little stress testing of USB, to make sure things are otherwise really happy (eth and perhaps a USB stick)? Thanks alot!
On 2012-07-12 03:30, Tom Rini wrote:
On Thu, Jul 12, 2012 at 02:20:18AM -0700, Tom Rini wrote:
On Wed, Jul 11, 2012 at 07:08:50AM -0600, Gary Thomas wrote:
I just tried rev 211e47549b668c7cdd8658c0413a272f0d0495d4 (v2012.07-rc1) for my PandaBoard. Sadly, this is failing when I try to use the onboard ethernet (EHCI USB based) controller:
Sorry for the late response, at a conference. This is a known problem and we will either have this fixed soon (Ilya Yanok is working on a series) or we will build-time disable dcache support on these boards and fix this properly for the next release.
In short, some cache clean-ups in ehci-hcd.c exposed other cache problems on other platforms where our cache size is 64 not 32bytes.
I take it back, I forgot omap4 is 32byte cache. With the fix that Tetsuyuki Kobayashi pointed you at (oh, and a Tested-by to that thread if you can), can you please do a little stress testing of USB, to make sure things are otherwise really happy (eth and perhaps a USB stick)? Thanks alot!
Yesterday, this was working great. This morning, when I turned on the board, it can no longer find anything on the USB bus - nothing at all. This also applies to Linux when I boot from SD. I'm really confused :-(
If I boot the board using the 2011.06 U-Boot, all is happy again. It looks like the USB HUB (USB3320) seems to be stuck in reset when I use the latest U-Boot.
Ever hear of any problems like this?
Thanks
On Thu, Jul 12, 2012 at 07:06:02AM -0600, Gary Thomas wrote:
On 2012-07-12 03:30, Tom Rini wrote:
On Thu, Jul 12, 2012 at 02:20:18AM -0700, Tom Rini wrote:
On Wed, Jul 11, 2012 at 07:08:50AM -0600, Gary Thomas wrote:
I just tried rev 211e47549b668c7cdd8658c0413a272f0d0495d4 (v2012.07-rc1) for my PandaBoard. Sadly, this is failing when I try to use the onboard ethernet (EHCI USB based) controller:
Sorry for the late response, at a conference. This is a known problem and we will either have this fixed soon (Ilya Yanok is working on a series) or we will build-time disable dcache support on these boards and fix this properly for the next release.
In short, some cache clean-ups in ehci-hcd.c exposed other cache problems on other platforms where our cache size is 64 not 32bytes.
I take it back, I forgot omap4 is 32byte cache. With the fix that Tetsuyuki Kobayashi pointed you at (oh, and a Tested-by to that thread if you can), can you please do a little stress testing of USB, to make sure things are otherwise really happy (eth and perhaps a USB stick)? Thanks alot!
Yesterday, this was working great. This morning, when I turned on the board, it can no longer find anything on the USB bus - nothing at all. This also applies to Linux when I boot from SD. I'm really confused :-(
If I boot the board using the 2011.06 U-Boot, all is happy again. It looks like the USB HUB (USB3320) seems to be stuck in reset when I use the latest U-Boot.
Ever hear of any problems like this?
How about if you turn the dcache off at run or build time?
On 2012-07-12 07:15, Tom Rini wrote:
On Thu, Jul 12, 2012 at 07:06:02AM -0600, Gary Thomas wrote:
On 2012-07-12 03:30, Tom Rini wrote:
On Thu, Jul 12, 2012 at 02:20:18AM -0700, Tom Rini wrote:
On Wed, Jul 11, 2012 at 07:08:50AM -0600, Gary Thomas wrote:
I just tried rev 211e47549b668c7cdd8658c0413a272f0d0495d4 (v2012.07-rc1) for my PandaBoard. Sadly, this is failing when I try to use the onboard ethernet (EHCI USB based) controller:
Sorry for the late response, at a conference. This is a known problem and we will either have this fixed soon (Ilya Yanok is working on a series) or we will build-time disable dcache support on these boards and fix this properly for the next release.
In short, some cache clean-ups in ehci-hcd.c exposed other cache problems on other platforms where our cache size is 64 not 32bytes.
I take it back, I forgot omap4 is 32byte cache. With the fix that Tetsuyuki Kobayashi pointed you at (oh, and a Tested-by to that thread if you can), can you please do a little stress testing of USB, to make sure things are otherwise really happy (eth and perhaps a USB stick)? Thanks alot!
Yesterday, this was working great. This morning, when I turned on the board, it can no longer find anything on the USB bus - nothing at all. This also applies to Linux when I boot from SD. I'm really confused :-(
If I boot the board using the 2011.06 U-Boot, all is happy again. It looks like the USB HUB (USB3320) seems to be stuck in reset when I use the latest U-Boot.
Ever hear of any problems like this?
How about if you turn the dcache off at run or build time?
Sorry for being thick, but how do I do that? I don't see any cache manipulation commands in 'help'
On Thu, Jul 12, 2012 at 07:17:59AM -0600, Gary Thomas wrote:
On 2012-07-12 07:15, Tom Rini wrote:
On Thu, Jul 12, 2012 at 07:06:02AM -0600, Gary Thomas wrote:
On 2012-07-12 03:30, Tom Rini wrote:
On Thu, Jul 12, 2012 at 02:20:18AM -0700, Tom Rini wrote:
On Wed, Jul 11, 2012 at 07:08:50AM -0600, Gary Thomas wrote:
I just tried rev 211e47549b668c7cdd8658c0413a272f0d0495d4 (v2012.07-rc1) for my PandaBoard. Sadly, this is failing when I try to use the onboard ethernet (EHCI USB based) controller:
Sorry for the late response, at a conference. This is a known problem and we will either have this fixed soon (Ilya Yanok is working on a series) or we will build-time disable dcache support on these boards and fix this properly for the next release.
In short, some cache clean-ups in ehci-hcd.c exposed other cache problems on other platforms where our cache size is 64 not 32bytes.
I take it back, I forgot omap4 is 32byte cache. With the fix that Tetsuyuki Kobayashi pointed you at (oh, and a Tested-by to that thread if you can), can you please do a little stress testing of USB, to make sure things are otherwise really happy (eth and perhaps a USB stick)? Thanks alot!
Yesterday, this was working great. This morning, when I turned on the board, it can no longer find anything on the USB bus - nothing at all. This also applies to Linux when I boot from SD. I'm really confused :-(
If I boot the board using the 2011.06 U-Boot, all is happy again. It looks like the USB HUB (USB3320) seems to be stuck in reset when I use the latest U-Boot.
Ever hear of any problems like this?
How about if you turn the dcache off at run or build time?
Sorry for being thick, but how do I do that? I don't see any cache manipulation commands in 'help'
Looks like omap4 doesn't have CONFIG_CMD_CACHE set, so indeed you're missing 'dcache off' as a command. The other one is to add CONFIG_SYS_DCACHE_OFF to omap4_panda.h (or omap4_common.h) and rebuild.
On 2012-07-12 07:20, Tom Rini wrote:
On Thu, Jul 12, 2012 at 07:17:59AM -0600, Gary Thomas wrote:
On 2012-07-12 07:15, Tom Rini wrote:
On Thu, Jul 12, 2012 at 07:06:02AM -0600, Gary Thomas wrote:
On 2012-07-12 03:30, Tom Rini wrote:
On Thu, Jul 12, 2012 at 02:20:18AM -0700, Tom Rini wrote:
On Wed, Jul 11, 2012 at 07:08:50AM -0600, Gary Thomas wrote:
> I just tried rev 211e47549b668c7cdd8658c0413a272f0d0495d4 (v2012.07-rc1) > for my PandaBoard. Sadly, this is failing when I try to use the onboard > ethernet (EHCI USB based) controller:
Sorry for the late response, at a conference. This is a known problem and we will either have this fixed soon (Ilya Yanok is working on a series) or we will build-time disable dcache support on these boards and fix this properly for the next release.
In short, some cache clean-ups in ehci-hcd.c exposed other cache problems on other platforms where our cache size is 64 not 32bytes.
I take it back, I forgot omap4 is 32byte cache. With the fix that Tetsuyuki Kobayashi pointed you at (oh, and a Tested-by to that thread if you can), can you please do a little stress testing of USB, to make sure things are otherwise really happy (eth and perhaps a USB stick)? Thanks alot!
Yesterday, this was working great. This morning, when I turned on the board, it can no longer find anything on the USB bus - nothing at all. This also applies to Linux when I boot from SD. I'm really confused :-(
If I boot the board using the 2011.06 U-Boot, all is happy again. It looks like the USB HUB (USB3320) seems to be stuck in reset when I use the latest U-Boot.
Ever hear of any problems like this?
How about if you turn the dcache off at run or build time?
Sorry for being thick, but how do I do that? I don't see any cache manipulation commands in 'help'
Looks like omap4 doesn't have CONFIG_CMD_CACHE set, so indeed you're missing 'dcache off' as a command. The other one is to add CONFIG_SYS_DCACHE_OFF to omap4_panda.h (or omap4_common.h) and rebuild.
No difference, sorry.
On 2012-07-12 07:27, Gary Thomas wrote:
On 2012-07-12 07:20, Tom Rini wrote:
On Thu, Jul 12, 2012 at 07:17:59AM -0600, Gary Thomas wrote:
On 2012-07-12 07:15, Tom Rini wrote:
On Thu, Jul 12, 2012 at 07:06:02AM -0600, Gary Thomas wrote:
On 2012-07-12 03:30, Tom Rini wrote:
On Thu, Jul 12, 2012 at 02:20:18AM -0700, Tom Rini wrote: > On Wed, Jul 11, 2012 at 07:08:50AM -0600, Gary Thomas wrote: > >> I just tried rev 211e47549b668c7cdd8658c0413a272f0d0495d4 (v2012.07-rc1) >> for my PandaBoard. Sadly, this is failing when I try to use the onboard >> ethernet (EHCI USB based) controller: > > Sorry for the late response, at a conference. This is a known problem > and we will either have this fixed soon (Ilya Yanok is working on a > series) or we will build-time disable dcache support on these boards and > fix this properly for the next release. > > In short, some cache clean-ups in ehci-hcd.c exposed other cache > problems on other platforms where our cache size is 64 not 32bytes.
I take it back, I forgot omap4 is 32byte cache. With the fix that Tetsuyuki Kobayashi pointed you at (oh, and a Tested-by to that thread if you can), can you please do a little stress testing of USB, to make sure things are otherwise really happy (eth and perhaps a USB stick)? Thanks alot!
Yesterday, this was working great. This morning, when I turned on the board, it can no longer find anything on the USB bus - nothing at all. This also applies to Linux when I boot from SD. I'm really confused :-(
If I boot the board using the 2011.06 U-Boot, all is happy again. It looks like the USB HUB (USB3320) seems to be stuck in reset when I use the latest U-Boot.
Ever hear of any problems like this?
How about if you turn the dcache off at run or build time?
Sorry for being thick, but how do I do that? I don't see any cache manipulation commands in 'help'
Looks like omap4 doesn't have CONFIG_CMD_CACHE set, so indeed you're missing 'dcache off' as a command. The other one is to add CONFIG_SYS_DCACHE_OFF to omap4_panda.h (or omap4_common.h) and rebuild.
No difference, sorry.
After some poking around, I found that the GPIO pins used by the USB (GPIO_1 = hub power, GPIO_62 = hub reset) were not muxed at all. This left those signals (and many others) in strange limbo.
Adding CONFIG_SYS_ENABLE_PADS_ALL brought it back to life and the network is working once more.
On Thu, Jul 12, 2012 at 08:26:55AM -0600, Gary Thomas wrote:
On 2012-07-12 07:27, Gary Thomas wrote:
On 2012-07-12 07:20, Tom Rini wrote:
On Thu, Jul 12, 2012 at 07:17:59AM -0600, Gary Thomas wrote:
On 2012-07-12 07:15, Tom Rini wrote:
On Thu, Jul 12, 2012 at 07:06:02AM -0600, Gary Thomas wrote:
On 2012-07-12 03:30, Tom Rini wrote: >On Thu, Jul 12, 2012 at 02:20:18AM -0700, Tom Rini wrote: >>On Wed, Jul 11, 2012 at 07:08:50AM -0600, Gary Thomas wrote: >> >>>I just tried rev 211e47549b668c7cdd8658c0413a272f0d0495d4 (v2012.07-rc1) >>>for my PandaBoard. Sadly, this is failing when I try to use the onboard >>>ethernet (EHCI USB based) controller: >> >>Sorry for the late response, at a conference. This is a known problem >>and we will either have this fixed soon (Ilya Yanok is working on a >>series) or we will build-time disable dcache support on these boards and >>fix this properly for the next release. >> >>In short, some cache clean-ups in ehci-hcd.c exposed other cache >>problems on other platforms where our cache size is 64 not 32bytes. > >I take it back, I forgot omap4 is 32byte cache. With the fix that >Tetsuyuki Kobayashi pointed you at (oh, and a Tested-by to that thread >if you can), can you please do a little stress testing of USB, to make >sure things are otherwise really happy (eth and perhaps a USB stick)? >Thanks alot! >
Yesterday, this was working great. This morning, when I turned on the board, it can no longer find anything on the USB bus - nothing at all. This also applies to Linux when I boot from SD. I'm really confused :-(
If I boot the board using the 2011.06 U-Boot, all is happy again. It looks like the USB HUB (USB3320) seems to be stuck in reset when I use the latest U-Boot.
Ever hear of any problems like this?
How about if you turn the dcache off at run or build time?
Sorry for being thick, but how do I do that? I don't see any cache manipulation commands in 'help'
Looks like omap4 doesn't have CONFIG_CMD_CACHE set, so indeed you're missing 'dcache off' as a command. The other one is to add CONFIG_SYS_DCACHE_OFF to omap4_panda.h (or omap4_common.h) and rebuild.
No difference, sorry.
After some poking around, I found that the GPIO pins used by the USB (GPIO_1 = hub power, GPIO_62 = hub reset) were not muxed at all. This left those signals (and many others) in strange limbo.
Adding CONFIG_SYS_ENABLE_PADS_ALL brought it back to life and the network is working once more.
OK. Can you confirm if f3f98bb0b8cc520e08ea2bdfc3f9cbe4e4ac29f5 is what breaks / unbreaks things? The USB pins are supposed to all be set (1a89a217f5c5ab3645c80c1247e8911a8b5ad491) but perhaps some got missed.
On 2012-07-12 10:16, Tom Rini wrote:
On Thu, Jul 12, 2012 at 08:26:55AM -0600, Gary Thomas wrote:
On 2012-07-12 07:27, Gary Thomas wrote:
On 2012-07-12 07:20, Tom Rini wrote:
On Thu, Jul 12, 2012 at 07:17:59AM -0600, Gary Thomas wrote:
On 2012-07-12 07:15, Tom Rini wrote:
On Thu, Jul 12, 2012 at 07:06:02AM -0600, Gary Thomas wrote: > On 2012-07-12 03:30, Tom Rini wrote: >> On Thu, Jul 12, 2012 at 02:20:18AM -0700, Tom Rini wrote: >>> On Wed, Jul 11, 2012 at 07:08:50AM -0600, Gary Thomas wrote: >>> >>>> I just tried rev 211e47549b668c7cdd8658c0413a272f0d0495d4 (v2012.07-rc1) >>>> for my PandaBoard. Sadly, this is failing when I try to use the onboard >>>> ethernet (EHCI USB based) controller: >>> >>> Sorry for the late response, at a conference. This is a known problem >>> and we will either have this fixed soon (Ilya Yanok is working on a >>> series) or we will build-time disable dcache support on these boards and >>> fix this properly for the next release. >>> >>> In short, some cache clean-ups in ehci-hcd.c exposed other cache >>> problems on other platforms where our cache size is 64 not 32bytes. >> >> I take it back, I forgot omap4 is 32byte cache. With the fix that >> Tetsuyuki Kobayashi pointed you at (oh, and a Tested-by to that thread >> if you can), can you please do a little stress testing of USB, to make >> sure things are otherwise really happy (eth and perhaps a USB stick)? >> Thanks alot! >> > > Yesterday, this was working great. This morning, when I turned on > the board, it can no longer find anything on the USB bus - nothing at > all. This also applies to Linux when I boot from SD. I'm really > confused :-( > > If I boot the board using the 2011.06 U-Boot, all is happy again. > It looks like the USB HUB (USB3320) seems to be stuck in reset when > I use the latest U-Boot. > > Ever hear of any problems like this?
How about if you turn the dcache off at run or build time?
Sorry for being thick, but how do I do that? I don't see any cache manipulation commands in 'help'
Looks like omap4 doesn't have CONFIG_CMD_CACHE set, so indeed you're missing 'dcache off' as a command. The other one is to add CONFIG_SYS_DCACHE_OFF to omap4_panda.h (or omap4_common.h) and rebuild.
No difference, sorry.
After some poking around, I found that the GPIO pins used by the USB (GPIO_1 = hub power, GPIO_62 = hub reset) were not muxed at all. This left those signals (and many others) in strange limbo.
Adding CONFIG_SYS_ENABLE_PADS_ALL brought it back to life and the network is working once more.
OK. Can you confirm if f3f98bb0b8cc520e08ea2bdfc3f9cbe4e4ac29f5 is what breaks / unbreaks things? The USB pins are supposed to all be set (1a89a217f5c5ab3645c80c1247e8911a8b5ad491) but perhaps some got missed.
Correct.
Reverting f3f98bb0b8cc520e08ea2bdfc3f9cbe4e4ac29f5 solves the problem in general. That's what I discovered on my own.
Without CONFIG_SYS_ENABLE_PADS_ALL, the changes in 1a89a217f5c5ab3645c80c1247e8911a8b5ad491 leave out platform specific pins, in particular the GPIO pins used by the USB HUB. Perhaps they should be defined in a different section?
I am loathe to experiment much with this as the board is 6000 miles away. If I mess up something, the network breaks and the only way to fix it is to take out the SD card and reprogram it on a PC - something I can only do with on-site help and they've all gone home for the night :-) If you need me to work this more, it'll have to wait until tomorrow.
participants (3)
-
Gary Thomas -
Tetsuyuki Kobayashi -
Tom Rini