arm: Fix minor mistake in cache maintenance assembly

Turns out that when you clear 28 bits starting with bit 3, you leave bit
31 standing. Ooops...

This shouldn't really matter since that bit is reserved/SBZ in CLIDR
anyway, but it's still nice to fix it. This whole thing should really be
an AND for clarity anyway in my opinion.

Bug found in upstream NetBSD (who would've thought...).

BUG=None
TEST=Still boots.

Change-Id: Ic826e82d58fd1ce984971afea3dfa9296f746d9f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193300
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit d270c0ec18b74b272451c456cbf07e99d95896cb)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7745
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This commit is contained in:
Julius Werner 2014-04-04 14:01:15 -07:00 committed by Marc Jones
parent 703e507fa0
commit 638015b98b
2 changed files with 2 additions and 2 deletions

View File

@ -60,7 +60,7 @@
add r2, r3, r3, lsr #1 @ r2 = (level << 1) * 3 / 2
mov r1, r0, lsr r2 @ r1 = cache type
bfc r1, #3, #28
and r1, r1, #7
cmp r1, #2 @ is it data or i&d?
blt 1b @next_level @ nope, skip level

View File

@ -60,7 +60,7 @@
add r2, r3, r3, lsr #1 @ r2 = (level << 1) * 3 / 2
mov r1, r0, lsr r2 @ r1 = cache type
bfc r1, #3, #28
and r1, r1, #7
cmp r1, #2 @ is it data or i&d?
blt 1b @next_level @ nope, skip level