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

[Albert ARIBAUD]

Le 06/10/2010 19:36, Albert ARIBAUD a écrit :
> Le 06/10/2010 17:56, Albert ARIBAUD a écrit :
>> Le 06/10/2010 16:22, Prafulla Wadaskar a écrit :
>>>
>>>
>>>> -----Original Message-----
>>>> From: Wolfgang Denk [mailto:wd at denx.de]
>>>> Sent: Wednesday, October 06, 2010 7:00 PM
>>>> To: Prafulla Wadaskar
>>>> Cc: Albert ARIBAUD; u-boot at lists.denx.de; Ashish Karkare;
>>>> Prabhanjan Sarnaik
>>>> Subject: Re: [U-Boot] Mvbge driver broken on kirkwood
>>>> platforms after ARM relocation
>>>>
>>>> Dear Prafulla Wadaskar,
>>>>
>>>> In message
>>>> <F766E4F80769BD478052FB6533FA745D19A69E25C8 at SC-VEXCH4.marvell.
>>>> com> you wrote:
>>>>>
>>>>> After rebasing to new ARM relocation code base and updating
>>>> Kirkwood board support.
>>>>> I am unable to get my network driver through (mvgbe)
>>>>>
>>>>> Have you tested this on edminv2 platform?
>>>>> If it is working at your end? Can you please cross check
>>>> the same with Kirkwood platform?
>>>>
>>>> Try running the "dcache off" command before accessing the network and
>>>> see if this changes anything.
>>>
>>> I tried this too, I have disabled dcache in init.
>>> .. no difference.
>>>
>>> Debugging continued..
>>>
>>> Regards..
>>> Prafulla . .
>>
>> Trying this on an openrd client board with the openrd_base config. Both
>> boards have the same exact RAMs, however the DRAM: line is acting funny
>> on me: fresh with my relocation patch above master, it says:
>>
>> SoC: Kirkwood 88F6281_A0
>> DRAM: 192.5 MiB
>>
>> ... while the actual RAM size is 512 MiB.
>>
>> (Even considering that the original Marvell code may have the
>> count-only-half bug that Chris' patch fixes, that's only 385 MiB...
>> Weirder yet: adding Chris' patch above mine, I get 3.6 GiB... But let's
>> chase only one rabbit at a time)
>>
>> Prafulla, how much RAM does your build see on your board(s)?
>
> globally defining DEBUG gives:
>
> U-Boot 2010.09-00102-gb4a7c1c-dirty (Oct 06 2010 - 19:13:59)
> OpenRD_base
>
> U-Boot code: 00600000 -> 0065DFBC BSS: -> 006A46E0
> SoC: Kirkwood 88F6281_A0
> monitor len: 000A46E0
> ramsize: 00000000
>
> Obviously RAM detection is bugged. This explains the following
> computations:
>
> TLB table at: ffff0000
> Top of RAM usable for U-Boot at: ffff0000
> Reserving 657k for U-Boot at: fff4b000
> Reserving 1152k for malloc() at: ffe2b000
> Reserving 48 Bytes for Board Info at: ffe2afd0
> Reserving 92 Bytes for Global Data at: ffe2af74
> New Stack Pointer is: ffe2af70
>
>
> RAM Configuration:
> Bank #0: 00000000 0 Bytes
> Bank #1: 00000000 0 Bytes
> Bank #2: 00000000 0 Bytes
> Bank #3: 00000000 3.3 GiB
>
> This weird bank #3 one may be a consequence, or not, of the buggy RAM
> computation.
>
> relocation Offset is: ff94b000
>
> Further debugging going on.

I think I got it.

You must define dram_init() and dram_init_banksize() in your board code 
(or in the SoC code if you can factorize it). Without it, default 
functions get called, and that does not work out well.

You can probably define dram_init() and dram_init_banksize() in the 
kirkwood SoC support code, like it is for orion5x.

Amicalement,
-- 
Albert.