From: Alexander Graf <agraf@suse.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/5] arm64: Add 32bit arm compatible dcache definitions
Date: Wed, 16 Mar 2016 23:31:16 +0100 [thread overview]
Message-ID: <56E9DEB4.7050501@suse.de> (raw)
In-Reply-To: <56E99E2B.1030409@suse.de>
On 16.03.16 18:55, Andreas F?rber wrote:
> Am 15.03.2016 um 18:21 schrieb Alexander Graf:
>> We want to be able to reuse device drivers from 32bit code, so let's add
>> definitions for all the dcache options that 32bit code has.
>>
>> While at it, fix up the DCACHE_OFF configuration. That was setting the bits
>> to declare a PTE a PTE and left the MAIR index bit at 0. Drop the useless
>> bits and make the index explicit.
>>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> ---
>> arch/arm/include/asm/system.h | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
>> index ac1173d..832c1db 100644
>> --- a/arch/arm/include/asm/system.h
>> +++ b/arch/arm/include/asm/system.h
>> @@ -26,8 +26,12 @@ u64 get_page_table_size(void);
>> #define MMU_SECTION_SHIFT 21
>> #define MMU_SECTION_SIZE (1 << MMU_SECTION_SHIFT)
>>
>> +/* These constants need to be synced to the MT_ types in asm/armv8/mmu.h */
>> enum dcache_option {
>> - DCACHE_OFF = 0x3,
>> + DCACHE_OFF = 0 << 2,
>> + DCACHE_WRITETHROUGH = 3 << 2,
>> + DCACHE_WRITEBACK = 4 << 2,
>> + DCACHE_WRITEALLOC = 4 << 2,
>
> Is it intentional that these two have the same value?
Yes. We don't have any MAIR entry on AArch64 that defines writeback
without alloc:
#define MT_DEVICE_NGNRNE 0
#define MT_DEVICE_NGNRE 1
#define MT_DEVICE_GRE 2
#define MT_NORMAL_NC 3
#define MT_NORMAL 4
#define MEMORY_ATTRIBUTES ((0x00 << (MT_DEVICE_NGNRNE * 8)) | \
(0x04 << (MT_DEVICE_NGNRE * 8)) | \
(0x0c << (MT_DEVICE_GRE * 8)) | \
(0x44 << (MT_NORMAL_NC * 8)) | \
(UL(0xff) << (MT_NORMAL * 8)))
So MAIR entries 0-4 are:
0: Device memory, Device-nGnRnE memory
1: Device memory, Device-nGnRE memory
2: Device memory, Device-GRE memory
3: Normal Memory, Outer Non-Cacheable, Inner Non-Cacheable
4: Normal Memory, Outer Write-back non-transient, Outer Read Allocate,
Outer Write Allocate, Inner Write-back non-transient, Inner Read
Allocate, Inner Write Allocate
But on armv7 we map memory as non-allocated by default. So I wanted to
make sure we stay compatible with our RAM maps. Basically on armv8,
"writeback" and "writealloc" both mean "cached RAM".
Alex
next prev parent reply other threads:[~2016-03-16 22:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-15 17:21 [U-Boot] [PATCH 0/5] Enable caches for the RPi2 Alexander Graf
2016-03-15 17:21 ` [U-Boot] [PATCH 1/5] arm64: Add 32bit arm compatible dcache definitions Alexander Graf
2016-03-16 17:55 ` Andreas Färber
2016-03-16 22:31 ` Alexander Graf [this message]
2016-03-15 17:21 ` [U-Boot] [PATCH 2/5] arm: Add support for HYP mode and LPAE page tables Alexander Graf
2016-03-15 17:35 ` Tom Rini
2016-03-16 8:33 ` Alexander Graf
2016-03-16 14:25 ` Tom Rini
2016-03-15 17:21 ` [U-Boot] [PATCH 3/5] lcd: Fix compile warning in 64bit mode Alexander Graf
2016-03-15 17:21 ` [U-Boot] [PATCH 4/5] RPi: Enable caches for rpi2 Alexander Graf
2016-03-15 17:21 ` [U-Boot] [PATCH 5/5] bcm2835 video: Map fb as cached Alexander Graf
2016-03-16 18:00 ` Andreas Färber
2016-03-16 22:32 ` Alexander Graf
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=56E9DEB4.7050501@suse.de \
--to=agraf@suse.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.