From mboxrd@z Thu Jan  1 00:00:00 1970
From: Richard Danter <richard.danter@ntlworld.com>
Date: Fri, 15 Jul 2005 15:29:44 +0100
Subject: [U-Boot-Users] Global vars question (was 7xx/74xx cache question)
In-Reply-To: <42D7C22B.4000205@ntlworld.com>
References: <42D7C22B.4000205@ntlworld.com>
Message-ID: <42D7C858.2050104@ntlworld.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Richard Danter wrote:
> Hi all,
> 
> Further progress on my port. I can now write to flash!
> 
> I noticed in lib_ppc/board.c board_init_r() that on e500 CPU's the 
> unlock_ram_in_cache() function is called. The 7xx/74xx also locks the 
> init RAM in the dcache, but nowhere is it unlocked.
> 
> I tried calling unlock_ram_in_cache() from my board's misc_init_r() 
> function, but this crashes U-Boot.
> 
> As an experiment, I left the cache locked, but then ran the "dcache off" 
> command from the shell. If I do printenv before turning the dcache off 
> it is all OK, if I do it after then it crashes.
> 
> With my debugger I can see that the gd data structure is garbage when 
> env_get_char_memory() is called. But I thought all data was copied to 
> the main sys RAM.
> 
> Is there something else I need to do before/after calling 
> unlock_ram_in_cache() so I can use the D-Cache as normal?

Since I now have system RAM initialised very early on, I tried using the 
system RAM instead of the dcache for init RAM. That works fine. I do not 
now need to call unlock_ram_in_cache() and I can turn the dcache off/on 
without breaking printenv.

Just to check things out,I used "mw" to write a pattern over where the 
init RAM is placed. After that, printenv fails again. So it seems 
something is wrong within the relocation of global variables.

I have not changed the code to do the relocation, so am I just 
misunderstanding what it does? Is there some #define I may have forgotten?

Thanks,
Rich