linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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/  |

             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).