[U-Boot] Ethernet on PandaBoard

Gary Thomas
2012-07-12T16:44:49Z

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.