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.