> -----Original Message----- > From: Albert ARIBAUD [mailto:[email protected]] > Sent: Wednesday, October 06, 2010 11:24 PM > To: Albert ARIBAUD > Cc: Prafulla Wadaskar; [email protected]; Ashish Karkare; > [email protected]; 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:[email protected]] > >>>> Sent: Wednesday, October 06, 2010 7:00 PM > >>>> To: Prafulla Wadaskar > >>>> Cc: Albert ARIBAUD; [email protected]; Ashish Karkare; > >>>> Prabhanjan Sarnaik > >>>> Subject: Re: [U-Boot] Mvbge driver broken on kirkwood > >>>> platforms after ARM relocation > >>>> > >>>> Dear Prafulla Wadaskar, > >>>> > >>>> In message > >>>> <[email protected]. > >>>> 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. > _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
