public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: valerij zaporogeci <vlrzprgts@gmail.com>
Cc: edk2-devel <edk2-devel@lists.01.org>
Subject: Re: flat mapping vs identity mapping on ARM
Date: Thu, 22 Sep 2016 16:22:39 +0100	[thread overview]
Message-ID: <CAKv+Gu_7Nsa=mNs-+BuoNqfp21L=U71vns6gOs7+7sFxhVrdew@mail.gmail.com> (raw)
In-Reply-To: <CANPuzFw95u3q_JQ+2tTCuANNJjk+LppbyLWHNWq5BHmEgiMJqw@mail.gmail.com>

On 22 September 2016 at 16:19, valerij zaporogeci <vlrzprgts@gmail.com> wrote:
> 2016-09-22 18:03 GMT+03:00, Ard Biesheuvel <ard.biesheuvel@linaro.org>:
>> On 22 September 2016 at 15:30, valerij zaporogeci <vlrzprgts@gmail.com>
>> wrote:
>>> In the ARM architecture, there is such a thing - "flat mapping", where
>>> MMU stage 1 is disabled and the mapping done is 1:1 and attributes set
>>> to the predefined values.
>>
>> What do you mean by 'attributes set to the predefined values' ?
>>
>
> I meant what is written in the section B3.2.1, short quote:
> "For all other accesses, when a stage 1 MMU is disabled, the assigned
> attributes depend on whether
> the access is a data access or an instruction access, as follows:
> Data access
> The stage 1 translation assigns the Strongly-Ordered memory type"
>
> ... and then, more lengthy description for instruction access.
>
>

Yes, so what this means is that all data accesses are strongly
ordered, and instruction fetches are cacheable.

So while you can enable both the data and the instruction cache with
the MMU off, only the instruction cache is actually functional, since
all data accesses or non-cacheable


  reply	other threads:[~2016-09-22 15:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-22 14:30 flat mapping vs identity mapping on ARM valerij zaporogeci
2016-09-22 15:03 ` Ard Biesheuvel
2016-09-22 15:19   ` valerij zaporogeci
2016-09-22 15:22     ` Ard Biesheuvel [this message]
2016-09-22 15:23       ` Ard Biesheuvel
2016-09-22 15:34   ` Andrew Fish
2016-09-22 19:14     ` valerij zaporogeci

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-list 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='CAKv+Gu_7Nsa=mNs-+BuoNqfp21L=U71vns6gOs7+7sFxhVrdew@mail.gmail.com' \
    --to=devel@edk2.groups.io \
    /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