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

[Albert ARIBAUD <albert.aribaud@free.fr>]

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

Amicalement,
-- 
Albert.