[U-Boot-Users] 7xx/74xx cache question

[U-Boot-Users] 7xx/74xx cache question

[Richard Danter]

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?

Thanks
Rich

PS Calling icache_enable() from misc_init_r() seems to work fine.

[U-Boot-Users] Global vars question (was 7xx/74xx cache question)

[Richard Danter]

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

[U-Boot-Users] 7xx/74xx cache question

[Jerry Van Baren]

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?
> 
> Thanks
> Rich
> 
> PS Calling icache_enable() from misc_init_r() seems to work fine.

WRT data cache enabling, in order to enable data cache, you need to 
first set up BATs and/or the MMU page tables.  You need the MMU 
configured and enabled so that you can mark I/O space(s) to be 
uncached... by default every data access is cached which wreaks havoc 
with I/O (to put it lightly :-).

I am not aware of anybody doing this in u-boot because it is a major 
pain to do and minor benefit for the brief time you should be running in 
u-boot (but likely someone has).

When you boot your OS (e.g. linux), the OS should do its own MMU set up 
and data cache enabling.

WRT your locking question, I don't know.

gvb

[U-Boot-Users] 7xx/74xx cache question

[Richard Danter]

Jerry Van Baren 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?
>>
>> Thanks
>> Rich
>>
>> PS Calling icache_enable() from misc_init_r() seems to work fine.
> 
> 
> WRT data cache enabling, in order to enable data cache, you need to 
> first set up BATs and/or the MMU page tables.  You need the MMU 
> configured and enabled so that you can mark I/O space(s) to be 
> uncached... by default every data access is cached which wreaks havoc 
> with I/O (to put it lightly :-).

I have my BAT's set up such that the only area cacheable is the SDRAM. 
Accesses to PCI and Flash are cache inhibited.

> 
> I am not aware of anybody doing this in u-boot because it is a major 
> pain to do and minor benefit for the brief time you should be running in 
> u-boot (but likely someone has).
> 
> When you boot your OS (e.g. linux), the OS should do its own MMU set up 
> and data cache enabling.
> 
> WRT your locking question, I don't know.

No prob.

Thanks for the help.

As you may see by my other e-mail, I no longer think this is a cache 
problem. It seems the data is not being relocated correctly, probably 
because I have missed something somewhere....

Thanks again,
Rich

[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

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

[Wolfgang Denk]

In message <42D7DE58.3060005@ntlworld.com> you wrote:
>
> 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.

Care to submit a patch?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
He had quite a powerful intellect, but it  was  as  powerful  like  a
locomotive,  and  ran on rails and was therefore almost impossible to
steer.                          - Terry Pratchett, _Lords and Ladies_