From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Wed, 06 Oct 2010 19:36:46 +0200 Subject: [U-Boot] Mvbge driver broken on kirkwood platforms after ARM relocation In-Reply-To: <4CAC9C17.2000206@free.fr> References: <1286230940-26976-1-git-send-email-albert.aribaud@free.fr> <4CAB9B40.7090008@free.fr> <4CAC0E62.8030101@free.fr> <20101006133003.6D05C1539A0@gemini.denx.de> <4CAC9C17.2000206@free.fr> Message-ID: <4CACB3AE.3030800@free.fr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>> >> 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.