[U-Boot] Mvbge driver broken on kirkwood platforms after ARM relocation

[Albert ARIBAUD]

Le 06/10/2010 16:14, Prafulla Wadaskar a écrit :
>
>
>> -----Original Message-----
>> From: u-boot-bounces at lists.denx.de
>> [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Albert ARIBAUD
>> Sent: Wednesday, October 06, 2010 7:26 PM
>> To: Albert ARIBAUD
>> Cc: u-boot at lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik
>> Subject: Re: [U-Boot] Mvbge driver broken on kirkwood
>> platforms after ARM relocation
>>
>> Le 06/10/2010 15:54, Albert ARIBAUD a écrit :
>>
>>>>> Have you tested this on edminv2 platform?
>>>>> If it is working at your end? Can you please cross check
>> the same with Kirkwood platform?
>>>
>>> I am positive that mvgbe driver works, because it initially
>> did not on
>>> my edminiv2, and I traced the root cause to gd being trashed between
>>> board_init_f and board_init_r; that was fixed before I
>> submitted this patch.
>>>
>>> I will test on the openrd platform.
>>
>> BTW: Prafulla, what toolchain are you using for your kirkwood
>> platforms?
>
> Hi Albert
>
> I tried with Gcc ver 4.1.2 (Red Hat 4.1.2-33.fa1) and gcc ver 4.4.1 (Sourcery G++ Lite 2009q3-68)
> In both the cases it fails.
>
> Further I debugged the issue and found that- it fails in drivers/net/mvgbe.c at mvgbe_send() in while loop.
> It is clear that the Scheduled tx DMA xter is not getting completed, nor reporting error.
>
> Then I checked with other board having switch instead of phy, and it works !!.
>
> Whereas any release earlier to ARM relocation patches works very well (i.e. diff against u-boot-marvell.git/master and u-boot-arm.git)
>
> So I am unable to figure out whom to address?
>
> For me this happened since I moved to new ARM relocation code base. So initial doubt goes there.
>
> If you have openrd_base you can give a try
>
> Regards..
> Prafulla . .

This is suspiciously similar to the symptoms I had, which were: the loop 
checking for end of TX would never exit, because the TX descriptor's 
state word would never reflect the ownership change from DMA back to MPU 
that should happen at end of transfer, because the controllers BAR that 
was assumed to give it access to DRAM was trashed, because gd was 
trashed in the first place.

OTOH, if the same code works or not depending on whether you have a 
switch or phy, it rules out gd trashing.

Still... Please check the BARs in the controller.

I'll try on my openrd board. It has a phy, so I should be able to 
witness the issue.

Amicalement,
-- 
Albert.