[U-Boot-Users] Global vars question -- Solved

[Richard Danter]

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