From: "Anton Wöllert" <a.woellert@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] mips cache and relocate_code()
Date: Fri, 14 Apr 2006 13:47:28 +0200 [thread overview]
Message-ID: <443F8BD0.5070608@gmail.com> (raw)
In-Reply-To: <7DE680819FF6BF49974119663963FDB902D80D1E@USVAEX1.tellabs-west.tellabsinc.net>
Burch, John T. schrieb:
> Code is relocated from flash to RAM in cpu/mips/start.S/relocate_code().
> After the code is moved a comment in the code says, "If caches were
> enabled,
> we would have to flush them here." Based on code in the same file,
> the caches are enabled - and I agree that the data cache needs to be
> flushed,
> (and instruction cached invalidated to be safe) but it isn't.
> Is there a reason it's not?
>
> Also, flush_cache() is not implemented in cpu/mips/cpu.c. This function
> appears
> to be required by cmd_net.c/netboot_common(). Is there a reason
> flush_cache()
> is not implemented?
>
> I ask because I'm seeing unexplained code behavior that goes away if I
> don't
> enable the caches.
Hi, the reason why the cache is not flushed, is that
mips_cache_lock(stack pointer) (or so) is called before. This locks
the whole data cache beginning from the stack pointer. Any other
access to other addresses will not get into dcache, because the dcache
lines are locked against replacing. See MIPS spec. Unfortunately the
cache locking don't have to be implemented for MIPS 32 4Kc cpus. So
the code i think has to be improved. I've implemented a fluch_cache
routine to avoid the false behaviour, because the bcm47xx in my case
doesn't support it (as it seems for me). On the other side icache don't
has to be flushed before relocating, because the start code runs
uncached from KSEG1.
So my thoughts :)
Anton
next prev parent reply other threads:[~2006-04-14 11:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-13 16:27 [U-Boot-Users] mips cache and relocate_code() Burch, John T.
2006-04-14 11:47 ` Anton Wöllert [this message]
2006-05-23 9:59 ` Daniel Laird
2006-05-23 16:25 ` Anton Wöllert
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=443F8BD0.5070608@gmail.com \
--to=a.woellert@gmail.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