Skip to contentSkip to conversation

7xx/74xx cache question

U-Boot-Users Richard Danter 3 participants 6 messages Jul 15, 2005

lore
Share & tools
lore

Richard Danter

author
#0 lore raw

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.

author
#1 lore raw

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

Quoted 15 lines · 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.

Quoted 6 lines

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

#4 lore raw
In reply to Richard Danter
Quoted 19 lines · 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.

Quoted 7 lines

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

author
#5 lore raw
Quoted 27 lines · Jerry Van Baren
Quoted 25 lines · 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

Quoted 8 lines
Quoted 1 line

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.

Quoted 9 lines

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

author
#2 lore raw

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

In reply to Richard Danter
Quoted 30 lines · Richard Danter
Quoted 15 lines · 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.

Quoted 6 lines

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.

Quoted 6 lines

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

#3 lore raw

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

Quoted 7 lines · In message <[email protected]> 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

Signature · 5 lines
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_