From: Andre Przywara <andre.przywara@arm.com>
To: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
Cc: "u-boot@lists.denx.de" <u-boot@lists.denx.de>
Subject: Re: ARM A53 and initial MMU mapping for EL0/1/2/3 ?
Date: Wed, 9 Feb 2022 00:33:08 +0000 [thread overview]
Message-ID: <20220209003308.015c087d@slackpad.lan> (raw)
In-Reply-To: <52270ef295b438af775d6f00e3c6e97f6482d74c.camel@infinera.com>
On Tue, 8 Feb 2022 22:05:00 +0000
Joakim Tjernlund <Joakim.Tjernlund@infinera.com> wrote:
Hi Joakim,
> Trying to figure out how I should map the MMU for normal RAM so it acessible
> from all ELx security states.
^^^^^^^
This does not make much sense. U-Boot is typically running in one
exception level only, and sets up the page table for exactly that EL.
Each EL uses a separate translation regime (with some twists for stage
2 EL2 and combined EL1/0, plus VHE). If you map your memory in EL3, then
drop to EL2, the EL3 page tables become irrelevant.
So in U-Boot we just set up the page tables for the EL we are running
in, and leave the paging for the lower exception levels to be set up at
the discretion of our payloads (kernels, hypervisors).
Please not that *secure* memory is a separate concept, and handled by
external hardware, typically using regions, not page tables.
> So far I have this mem_map:
>
> /* memory mapped RAM. 32MB */
> .virt = 0x60000000UL,
> .phys = 0x60000000UL,
> .size = 0x02000000UL,
> .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) | PTE_BLOCK_INNER_SHARE
>
> but starting to doubt that is correct, can someone suggest what to put in the .attrs field?
Those are the correct attributes for normal ("cache-able") memory.
However you probably need at least another mapping for MMIO accesses,
which MUST NOT be cacheable (MT_DEVICE_NGNRNE), but device memory.
See the beginning of arch/arm/mach-sunxi/board.c for an example.
Cheers,
Andre
next prev parent reply other threads:[~2022-02-09 0:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-08 22:05 ARM A53 and initial MMU mapping for EL0/1/2/3 ? Joakim Tjernlund
2022-02-09 0:33 ` Andre Przywara [this message]
2022-02-09 8:35 ` Joakim Tjernlund
2022-02-09 10:45 ` Andre Przywara
2022-02-09 12:03 ` Joakim Tjernlund
2022-02-10 10:22 ` Andre Przywara
2022-02-10 21:58 ` Joakim Tjernlund
2022-02-10 22:43 ` Andre Przywara
2022-02-11 0:22 ` Joakim Tjernlund
2022-02-11 1:26 ` Andre Przywara
2022-02-11 14:00 ` Joakim Tjernlund
2022-02-11 17:00 ` Joakim Tjernlund
2022-02-17 15:13 ` Andre Przywara
2022-02-17 16:05 ` Joakim Tjernlund
2022-03-16 20:28 ` Joakim Tjernlund
2022-03-17 0:32 ` Andre Przywara
2022-03-18 12:22 ` Joakim Tjernlund
2022-02-09 13:05 ` Michael Walle
2022-02-09 13:13 ` Andre Przywara
2022-02-09 18:07 ` Joakim Tjernlund
2022-02-10 10:13 ` Andre Przywara
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=20220209003308.015c087d@slackpad.lan \
--to=andre.przywara@arm.com \
--cc=Joakim.Tjernlund@infinera.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox