[U-Boot-Users] 7xx/74xx cache question
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.
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
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
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
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
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
participants (3)
-
Jerry Van Baren -
Richard Danter -
Wolfgang Denk