From: u.kleine-koenig@pengutronix.de (Uwe Kleine-König)
To: linux-arm-kernel@lists.infradead.org
Subject: cache flushing for armv3 in zImage
Date: Tue, 26 Jan 2010 20:20:46 +0100 [thread overview]
Message-ID: <20100126192045.GA17642@pengutronix.de> (raw)
Hello,
I currently look into arch/arm/boot/compressed/head.S and wonder about
some cache functions:
- __armv3_mpu_cache_flush does:
mov r1, #0
mcr p15, 0, r0, c7, c0, 0 @ invalidate whole cache v3
mov pc, lr
why is r1 set to zero? I assume the register used in the mcr
instruction should be zero, but this uses r0, not r1.
- ARMv5TEJ uses __armv4_mmu_cache_flush not __armv5tej_mmu_cache_flush?
- __armv5tej_mmu_cache_flush calls
mcr p15, 0, r0, c7, c5, 0 @ flush I cache
mcr p15, 0, r0, c7, c10, 4 @ drain WB
without asserting that r0 is zero. ARM DDI 0198E (i.e. ARM926EJ-S
TRM) specifies the register should be zero. (I'm not sure this is
the right document.)
Ditto for __armv4_mmu_cache_flush. I assume both should first zero
r1 and then use r1 in the mcr instructions?
Ditto __armv3_mpu_cache_on:
mcr p15, 0, r0, c7, c0, 0
while r0 holds a value read by
mrc p15, 0, r0, c1, c0, 0
- __armv7_mmu_cache_flush corrupts r10, but this is not listed as
corrupted register in the comment describing cache_clean_flush.
As __armv7_mmu_cache_off calls __armv7_mmu_cache_flush there r10 is
corrupted, too which isn't explicitly allowed according to the
comment of cache_off either.
- __armv4_mpu_cache_on corrupts r0
__armv3_mpu_cache_on ditto
- __armv3_mpu_cache_on has:
mrc p15, 0, r0, c1, c0, 0 @ read control reg
@ .... .... .... WC.M
orr r0, r0, #0x000d @ .... .... .... 11.1
mov r0, #0
mcr p15, 0, r0, c1, c0, 0 @ write control reg
assuming that reading control reg and writing a recently read value
has no side effects all four instructions can go away.
- __armv3_mpu_cache_on does "invalidate whole cache v3" twice?
- the comment that r9 holds the run-time address of "start" on entry of
cache_on is wrong I think. If the zImage isn't relocated r9 isn't
touched until cacheon is called.
(r9 is used in __setup_mmu and then holds something that should be
the start of RAM. (The actual value is
(zreladdr - 0x4000) & ~0x3ffff
.))
Any thoughts on how to address these points?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
next reply other threads:[~2010-01-26 19:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-26 19:20 Uwe Kleine-König [this message]
2010-01-26 20:19 ` cache flushing for armv3 in zImage Russell King - ARM Linux
2010-01-26 20:38 ` Uwe Kleine-König
2010-01-26 21:28 ` [PATCH 1/4] zImage: fix comments for cache_on, cache_off and cache_clean_flush Uwe Kleine-König
2010-01-26 21:28 ` [PATCH 2/4] zImage: some comments for __armv3_mpu_cache_on Uwe Kleine-König
2010-01-26 21:28 ` [PATCH 3/4] zImage: __armv3_mpu_cache_flush: respect should-be-zero specification Uwe Kleine-König
2010-01-26 21:28 ` [PATCH 4/4] zImage: annotate debug functions about corrupted registers Uwe Kleine-König
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=20100126192045.GA17642@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).