Skip to contentSkip to conversation

Ethernet on PandaBoard

U-Boot Gary Thomas 3 participants 15 messages Jul 11, 2012 – Jul 12, 2012

lore
Share & tools
lore
#0 lore raw

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

Signature · 4 lines
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
#1 lore raw

Hi Gray,?

This wiki page might help you.
http://www.denx.de/wiki/view/DULG/DecodingUBootCrashDumps

Quoted 44 lines · Gary Thomas

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

#2 lore raw
In reply to Gary Thomas
Quoted 37 lines · Gary Thomas

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

Quoted 7 lines

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.

Signature · 4 lines
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
#3 lore raw

Hi Gray,

Quoted 46 lines · Gary Thomas
Quoted 37 lines · Gary Thomas

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

Quoted 7 lines

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

Quoted 8 lines

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

#4 lore raw
Quoted 60 lines · Tetsuyuki Kobayashi

Hi Gray,

Quoted 46 lines · Gary Thomas
Quoted 37 lines · Gary Thomas

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

Quoted 7 lines

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

Quoted 8 lines

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.

Quoted 5 lines

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.

Signature · 4 lines
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
#5 lore raw
In reply to Gary Thomas
Quoted 3 lines · Gary Thomas

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.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120712/4c57de9b/attachment.pgp>
#6 lore raw
Quoted 6 lines · Tom Rini
Quoted 3 lines · Gary Thomas

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:

Quoted 7 lines

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!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120712/18916882/attachment-0001.pgp>
#7 lore raw
Quoted 12 lines · Tom Rini
Quoted 11 lines · Tom Rini
Quoted 3 lines · Gary Thomas

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.

Quoted 9 lines
Quoted 2 lines

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

Signature · 4 lines
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
#8 lore raw
Quoted 28 lines · Gary Thomas
Quoted 12 lines · Tom Rini
Quoted 11 lines · Tom Rini
Quoted 3 lines · Gary Thomas

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.

Quoted 9 lines
Quoted 2 lines

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 :-(

Quoted 5 lines

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?

Signature · 1 line
Tom
#9 lore raw
Quoted 29 lines · Tom Rini
Quoted 28 lines · Gary Thomas
Quoted 12 lines · Tom Rini
Quoted 11 lines · Tom Rini
Quoted 3 lines · Gary Thomas

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.

Quoted 9 lines
Quoted 2 lines

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 :-(

Quoted 8 lines
Quoted 5 lines

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'

Signature · 4 lines
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
#10 lore raw
Quoted 34 lines · Gary Thomas
Quoted 33 lines · Tom Rini
Quoted 32 lines · Gary Thomas
Quoted 12 lines · Tom Rini
Quoted 11 lines · Tom Rini
Quoted 3 lines · Gary Thomas

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.

Quoted 9 lines
Quoted 2 lines

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.

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

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.

Signature · 1 line
Tom
#11 lore raw
Quoted 40 lines · Tom Rini
Quoted 39 lines · Gary Thomas
Quoted 37 lines · Tom Rini
Quoted 28 lines · Gary Thomas
Quoted 12 lines · Tom Rini
Quoted 11 lines · Tom Rini
Quoted 3 lines · Gary Thomas

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.

Quoted 9 lines
Quoted 2 lines

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 :-(

Quoted 5 lines

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?

Quoted 7 lines
Quoted 2 lines

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.

Signature · 4 lines
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
#12 lore raw
Quoted 44 lines · Gary Thomas
Quoted 43 lines · Tom Rini
Quoted 41 lines · Gary Thomas
Quoted 29 lines · Tom Rini
Quoted 28 lines · Gary Thomas
Quoted 12 lines · Tom Rini
Quoted 11 lines · Tom Rini
Quoted 3 lines · Gary Thomas

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.

Quoted 9 lines
Quoted 2 lines

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 :-(

Quoted 8 lines
Quoted 5 lines

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'

Quoted 7 lines
Quoted 4 lines

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.

Signature · 4 lines
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
#13 lore raw
Quoted 53 lines · Gary Thomas
Quoted 44 lines · Gary Thomas
Quoted 43 lines · Tom Rini
Quoted 41 lines · Gary Thomas
Quoted 29 lines · Tom Rini
Quoted 28 lines · Gary Thomas
Quoted 12 lines · Tom Rini
Quoted 11 lines · Tom Rini
Quoted 3 lines · Gary Thomas

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.

Quoted 9 lines
Quoted 2 lines

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 :-(

Quoted 8 lines
Quoted 5 lines

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'

Quoted 7 lines
Quoted 4 lines

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.

Quoted 6 lines

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.

Signature · 1 line
Tom
#14 lore raw
Quoted 58 lines · Tom Rini
Quoted 57 lines · Gary Thomas
Quoted 44 lines · Gary Thomas
Quoted 43 lines · Tom Rini
Quoted 41 lines · Gary Thomas
Quoted 29 lines · Tom Rini
Quoted 28 lines · Gary Thomas
Quoted 12 lines · Tom Rini
Quoted 11 lines · Tom Rini
Quoted 3 lines · Gary Thomas

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.

Quoted 9 lines
Quoted 2 lines

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 :-(

Quoted 8 lines
Quoted 5 lines

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'

Quoted 7 lines
Quoted 4 lines

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.

Quoted 7 lines
Quoted 2 lines

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.

Signature · 4 lines
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------