-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Wednesday, October 06, 2010 11:24 PM To: Albert ARIBAUD Cc: Prafulla Wadaskar; u-boot@lists.denx.de; Ashish Karkare; Prabhanjan@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@denx.de] Sent: Wednesday, October 06, 2010 7:00 PM To: Prafulla Wadaskar Cc: Albert ARIBAUD; u-boot@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.
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.