For armv8, U-Boot uses a static map defined as 'mem_map' for configuring
the MMU's page tables, done by mmu_setup.

Though this works well for simpler platforms, it makes creating runtime
carveouts by modifying the static array at runtime exceedingly complex
like in mach-snapdragon/board.c.

Creation of such carveouts are much better handled by APIs such as
mmu_change_region_attr once the page tables are configured. Usually such
carveouts are configured via the device-tree's reserved-memory node
which provides the address and size for the carveout.

Therefore this patch adds mmu_unmap_reserved_mem which acts as a wrapper
over mmu_change_region_attr, helping unmap a reserved-memory region.

Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

For armv8, U-Boot uses a static map defined as 'mem_map' for configuring
the MMU as part of mmu_setup.

But since the exact configuration of memory banks might not be known at
build time, many platforms such as imx9, versal2 etc. utilize
gd->bd->bi_dram to configure the static map at runtime.

Therefore this patch adds a new API mem_map_from_dram_banks that
modifies the static map in a similar way. Allowing the caller to map all
dram banks by just passing the index to last entry in their mem_map and
it's length.

Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

The mmu_setup function configures the page tables based on the board
supplied mem_map struct array. It is called implicitly as part of
dcache_enable but this limits us to only be able to use APIs such as
mmu_change_region_attr only after caches are enabled.

This might lead to speculative accesses before we can unmap a region
that is marked as cacheable in the static memory map.

Therefore this patch exports the mmu_setup function in mmu.h allowing
users to have more control over when the mmu is configured.

For K3 specifically this allows for the following configuration sequence
as part of enable_caches:

static mem_map fixups (TODO) -> mmu_setup -> carveouts using
mmu_change_region_attr (TODO) -> icache/dcache enable

Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

Add MIDR entry for Cortex-A720 core.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Add MIDR entries for Cortex-A55, Cortex-A73 and
Cortex-A75 cores and update the is_coretex_a entries.

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>

Upcoming patches are mapping memory with RO, RW^X etc permsissions.
Fix the meminfo command to display them properly

Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Add MIDR entries for Cortex-A57 and Cortex-A76 cores.
Those are used on R-Car Gen3 and Gen4 SoCs respectively.

Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Turn the core type check macros into inline functions to perform
better type checking on them. The inline functions get optimized
out in case they are not used. Indent the MIDR_PARTNUM_CORTEX_An
macros in preparation for addition of future three-digit cores
and use MIDR_PARTNUM_SHIFT in MIDR_PARTNUM_MASK to be consistent.

Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Caleb Connolly <caleb.connolly@linaro.org> says:

MMU issues are some of the most frustrating to debug. To make this
slightly less unbearable, introduce a software pagetable walker for
ARMv8. This can be called to dump a pagetable with the default
formatter, or a custom callback can be provided to implement more
complicated parsing.

This can also be useful to dump the pagetable used by a previous
bootloader stage (by reading out the ttbr register).

Here is an example of the output when walking U-Boot's own memory map
on a Qualcomm RB3 board:

Walking pagetable at 000000017df90000, va_bits: 36. Using 3 levels
[0x17df91000]                   |  Table |               |
  [0x17df92000]                 |  Table |               |
    [0x000001000 - 0x000200000] |  Pages | Device-nGnRnE | Non-shareable
  [0x000200000 - 0x040000000]   |  Block | Device-nGnRnE | Non-shareable
[0x040000000 - 0x080000000]     |  Block | Device-nGnRnE | Non-shareable
[0x080000000 - 0x140000000]     |  Block | Normal        | Inner-shareable
[0x17df93000]                   |  Table |               |
  [0x140000000 - 0x17de00000]   |  Block | Normal        | Inner-shareable
  [0x17df94000]                 |  Table |               |
    [0x17de00000 - 0x17dfa0000] |  Pages | Normal        | Inner-shareable

Add a basic software implementation of the ARM64 pagetable walker. This
can be used for debugging U-Boot's pagetable, as well as dumping the
pagetable from the previous bootloader stage if it used one (by reading
out the ttbr address).

One can either call dump_pagetable() to print the pagetable to the
console with the default formatter, or implement their own pagetable
handler using walke_pagetable() with a custom pte_walker_cb_t callback.

All of the added code is discarded when unused, hence there is no need
to add an additional Kconfig option for this.

Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>