From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Danter Date: Fri, 15 Jul 2005 17:03:36 +0100 Subject: [U-Boot-Users] Global vars question -- Solved In-Reply-To: <42D7C858.2050104@ntlworld.com> References: <42D7C22B.4000205@ntlworld.com> <42D7C858.2050104@ntlworld.com> Message-ID: <42D7DE58.3060005@ntlworld.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Richard Danter wrote: > 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? By default, the gd_t pointer (gd) remains pointing to init RAM, not to the relocated RAM on 7xx/74xx. I had to explicitly set gd to point to the relocated version in my after_reloc() function and ensure the correct value is passed to after_reloc() by start.S (relocate_code). Seems odd this is not the default. Rich