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

[Prafulla Wadaskar]

> -----Original Message-----
> From: Albert ARIBAUD [mailto:albert.aribaud at free.fr] 
> Sent: Wednesday, October 06, 2010 11:24 PM
> To: Albert ARIBAUD
> Cc: Prafulla Wadaskar; u-boot at lists.denx.de; Ashish Karkare; 
> Prabhanjan at theia.denx.de; Prabhanjan Sarnaik
> Subject: Re: Mvbge driver broken on kirkwood platforms after 
> ARM relocation
> 
> 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.

Hi Albert

You should apply these patches to get build errors and dram size fixed
http://lists.denx.de/pipermail/u-boot/2010-September/078069.html
http://lists.denx.de/pipermail/u-boot/2010-September/078071.html
http://lists.denx.de/pipermail/u-boot/2010-September/078070.html

Regards..
Prafulla . .

> 
> Amicalement,
> -- 
> Albert.
>