public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Richard Danter <richard.danter@ntlworld.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] 7xx/74xx cache question
Date: Fri, 15 Jul 2005 15:50:24 +0100	[thread overview]
Message-ID: <42D7CD30.6020301@ntlworld.com> (raw)
In-Reply-To: <42D7C917.6020800@smiths-aerospace.com>

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

      reply	other threads:[~2005-07-15 14:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-15 14:03 [U-Boot-Users] 7xx/74xx cache question Richard Danter
2005-07-15 14:29 ` [U-Boot-Users] Global vars question (was 7xx/74xx cache question) Richard Danter
2005-07-15 16:03   ` [U-Boot-Users] Global vars question -- Solved Richard Danter
2005-07-15 16:52     ` Wolfgang Denk
2005-07-15 14:32 ` [U-Boot-Users] 7xx/74xx cache question Jerry Van Baren
2005-07-15 14:50   ` Richard Danter [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42D7CD30.6020301@ntlworld.com \
    --to=richard.danter@ntlworld.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox