Nintendo Switch Brew - User contributions [en]

Dock

2019-03-14T07:51:22Z

Balika011:

The Dock is internally called "Cradle"(strings/symbols in system-titles).

The original dock was the HAC-CDH-MAIN-01.

There is an updated, costs down version of the dock out in the wild labeled as HAC-CDH-MAIN-10.
The release date is unknown. The guess is it came along with the patched 4.1 units.

== Components ==
{| class="wikitable"
! Function || Component on HAC-CDH-MAIN-01 || on HAC-CDH-MAIN-10 || Notes
|-
| MyDP -> HDMI Converter || colspan="2" | MegaChips STDP2550 "Mystique" || 2Mb flash contains firmware Based on STMicroelectronics Mystique family of DP converters.
|-
| USB Hub || VIA Labs VL210 USB 3.0 Hub Controller || Genesys Logic GL3510 || 512Kb flash is configuration storage
|-
| USB Device || colspan="2" | Cortex-M0 based (STM32F0-ish) "32P048"
| SWD clearly labelled and enabled Provides control of the Mystique Dumps (fw-1.0.0): [[:File:Dock.stm.08000000-08008000.bin|flash]] [[:File:Dock.stm.1fffc400-1ffffc00.bin|sysmem]] [[:File:Dock.stm.20000000-20001800.bin|SRAM]] [http://www.st.com/content/ccc/resource/technical/document/reference_manual/c2/f8/8a/f2/18/e6/43/96/DM00031936.pdf/files/DM00031936.pdf/jcr:content/translations/en.DM00031936.pdf Relevant manual]
|-
| rowspan="2" | Flash
| Macronix MX25L512E 512Kb CMOS || Unpopulated || [[:File:Dock.512K.bin|dump (fw-1.0.0)]]
|-
| Macronix MX25V2006E 2Mb CMOS || Windbond 25X20CLL04 || [[:File:Dock.2M.bin|dump (fw-1.0.0)]]
|-
| rowspan="2" | USB-PD
| colspan="2" | ROHM BM92T17 || rowspan="2" | One at i2c addr 0x18, the other at 0x1a [http://www.rohm.com/web/global/datasheet/BM92T10MWV/bm92t10mwv-e bm92t1x datasheet] [http://www.rohm.com/web/global/datasheet/BM92T50MWV/bm92t50mwv-e bm92t5x datasheet]
|-
| colspan="2" | ROHM BM92T55
|}
All 1.0.0 dumps were collected from a HAC-CDH-MAIN-01.

==Other Resources==
# [[List of compatible USB devices]]
# [https://www.ifixit.com/Teardown/Nintendo+Switch+Teardown/78263 iFixit's Nintendo Switch teardown]
# [https://github.com/dekuNukem/Nintendo_Switch_Reverse_Engineering dekuNukem's Reverse Engineering]

Dock

2019-03-14T00:21:33Z

Balika011: Add chips found on a mid 2017 dock (HAC-CDH-MAIN-10)

The Dock is internally called "Cradle"(strings/symbols in system-titles).

== Components ==
{| class="wikitable"
! Function || Component || Notes
|-
| MyDP -> HDMI Converter || MegaChips STDP2550 "Mystique" || 2Mb flash contains firmware Based on STMicroelectronics Mystique family of DP converters.
|-
| USB Hub || VIA Labs VL210 USB 3.0 Hub Controller / Genesys Logic GL3510 || 512Kb flash is configuration storage
|-
| USB Device || Cortex-M0 based (STM32F0-ish) "32P048"
| SWD clearly labelled and enabled Provides control of the Mystique Dumps (fw-1.0.0): [[:File:Dock.stm.08000000-08008000.bin|flash]] [[:File:Dock.stm.1fffc400-1ffffc00.bin|sysmem]] [[:File:Dock.stm.20000000-20001800.bin|SRAM]] [http://www.st.com/content/ccc/resource/technical/document/reference_manual/c2/f8/8a/f2/18/e6/43/96/DM00031936.pdf/files/DM00031936.pdf/jcr:content/translations/en.DM00031936.pdf Relevant manual]
|-
| rowspan="2" | Flash
| Macronix MX25L512E 512Kb CMOS / Nothing || [[:File:Dock.512K.bin|dump (fw-1.0.0)]]
|-
| Macronix MX25V2006E 2Mb CMOS / Windbond 25X20CLL04|| [[:File:Dock.2M.bin|dump (fw-1.0.0)]]
|-
| rowspan="2" | USB-PD
| ROHM BM92T17 || rowspan="2" | One at i2c addr 0x18, the other at 0x1a [http://www.rohm.com/web/global/datasheet/BM92T10MWV/bm92t10mwv-e bm92t1x datasheet] [http://www.rohm.com/web/global/datasheet/BM92T50MWV/bm92t50mwv-e bm92t5x datasheet]
|-
| ROHM BM92T55
|}

==Other Resources==
# [[List of compatible USB devices]]
# [https://www.ifixit.com/Teardown/Nintendo+Switch+Teardown/78263 iFixit's Nintendo Switch teardown]
# [https://github.com/dekuNukem/Nintendo_Switch_Reverse_Engineering dekuNukem's Reverse Engineering]

Testpads

2019-03-04T23:08:11Z

Balika011: Correct UART-A rx ad tx

The Nintendo Switch mainboard has a series of testpads on the front and back, presumably used in factory test, diagnostics, and early board bringup procedures.

== Raw Logic captures ==

These are reference materials, taken from poking at I/O on various testpads. https://github.com/hedgeberg/Switch-Logic-Captures

== Photos ==

[[File:Switchre_side1.jpg|200px]]
[[File:Switchre_side2.jpg|200px]]

== Pinouts ==

=== Cluster A ===

{| class=wikitable
! Pad # || Name || Type || Levels || Continuity || Frequency || Comment
|-
| 1 || Batt GND? || || || || ||
|-
| 2 || Battery pulse? || Pulse train || 0-3.3V || L-5? || ||
|-
| 3 || Battery Vdd || || || || ||
|-
| 4 || ?? || Square wave || 0-3.3V || || 329kHz? (undersampled?) || Square wave when screen on, but looks like vias to Speaker R
|-
| 5 || ?? || Square wave || 0-3.3V || || 329kHz? (undersampled?) || Square wave when screen on, but looks like vias to Speaker R
|-
| 6 || Weak GND? || || || || ||
|-
| 7 || SDA || I2C || 0-1.8V || || ||
|-
| 8 || SCL || I2C || 0-1.8V || || ||
|-
| 9 || USB-PWR-WAVE? || Square wave || 0-3.3V || K-4, K-5? || ~11 Hz ||
|-
| 10 || USB-PWR-WAVE? || Square wave || 0-3.3V || K-4, K-5? || ~11 Hz ||
|}

=== Cluster B ===

{| class=wikitable
! Pad # || Name || Type || Levels || Continuity || Frequency || Comment
|-
| 1 || || DBVDD || || || || from ALC5639 pin 43
|-
| 2 || D+ || USB-C || || || || Cluster B - 3
|-
| 3 || D- || USB-C || || || || Cluster B - 2
|-
| 4 || +3.3V || XRST || || || || from M92T36 pin 4
|-
| 5 || +3.3V || VSVR || || || || from M92T36 pin 6
|-
| 5(b) || VUSB || VB || || || || from M92T36 pin 9
|-
| 6 || GND || || || || ||
|}

=== Cluster C ===

{| class=wikitable
! Pad # || Name || Type || Levels || Continuity || Frequency || Comment
|-
| 1 || ?? || || 0-1.8V || || || No clue. This is definitely important, we just have no idea how. May need to interface with dock for comms.
|-
| 2 || UART-A TX || || 0-1.8V || || ||
|-
| 3 || UART-A RX || || 0-1.8V || || ||
|-
| 4 || ?? || || 0-1.8V || || ||
|-
| 5 || ?? || || 0-1.8V || || ||
|-
| 6 || ?? || || 0-1.8V || || ||
|-
| 7 || ?? || || 0-1.8V || || ||
|-
| 8 || ?? || || 0-1.8V || || ||
|-
| 9 || ?? || || 0-1.8V || || ||
|-
| 10 || ?? || || 0-1.8V || || ||
|-
| 11 || ?? || || 0-1.8V || || ||
|}

=== Cluster D ===

{| class=wikitable
! Pad # || Name || Type || Levels || Continuity || Frequency || Comment
|-
| 1 || GND || || || || ||
|-
| 4 || Seaker L + || || || || || Speaker Left +
|-
| 5 || Seaker L - || || || || || Speaker Left -
|}

=== Cluster E ===

{| class=wikitable
! Pad # || Name || Type || Levels || Continuity || Frequency || Comment
|-
| 1 || Vol (-) || || || || || Button Vol (-)
|-
| 10 || Reset || || || || ||
|-
| 11 || Vdd Referance|| || || || ||
|}

=== Cluster G ===

{| class=wikitable
! Pad # || Name || Type || Levels || Continuity || Frequency || Comment
|-
| 2 || GND || || || || ||
|-
| 4 || Vol(+) || || || || || Button Vol (+)
|-
| 5 || Li-Ion Batt Vdd Mirror || || || || || Power Supply
|-
| 9 || BUTTON_HOME || || || || || RCM strap
|}

=== Cluster I ===

{| class=wikitable
! Pad # || Name || Type || Levels || Continuity || Frequency || Comment
|-
| 1 || GND || || || || ||
|-
| 2 || Screen_on || On/Off || 0-1.8V || || || Screen power state, active high
|-
| 3 || || UART || 0-1.8V || || 1.5MBaud? ||
|-
| 4 || || UART || 0-1.8V || || 1.5MBaud? ||
|-
| 5 || || Flow control || 0-1.8V || || || Flow control for pad I-4?
|-
| 6 || || || 0-1.8V || || || Needs testing with chip/touch screen interface board plugged in
|}

=== Cluster J ===

{| class=wikitable
! Pad # || Name || Type || Levels || Continuity || Frequency || Comment
|-
| 1 || ? || Edge || 0-1.8V || || || Turns on around same time as pad J-3
|-
| 2 || GND || || || || ||
|-
| 3 || ? || Edge || 0-1.8V || || || Turns on around same time as pad J-1, slightly after
|-
| 4 || Power button || Pushbutton || 4V-0V || || || Active low
|-
| 5 || ? || Constant? || 0V || Ground?-NT || ||
|-
| 6 || ? || Edge || 0-1.8V || || || Turns on with pad J-6, ~1s after J-1/J-3
|-
| 7 || ? || Edge || 0-1.8V || || || Turns on with pad J-5, ~1s after J-1/J-3
|-
| 8 || ? || Edge? || 0-1.8V || || || Turns on ~1s after J-6/J-7, turns off at unknown point
|}

=== Cluster K ===

{| class=wikitable
! Pad # || Name || Type || Levels || Continuity || Frequency || Comment
|-
| 1 || GND || || || || ||
|-
| 2 || D- || USB-C || || || || Cluster B - 3
|-
| 3 || D+ || USB-C || || || || Cluster B - 2
|-
| 4 || USB-PWR-WAVE? || Square wave || 0V-3.3V || A-9, A-10? || ~11 Hz ||
|-
| 5 || USB-PWR-WAVE? || Square wave || 0V-3.3V || A-9, A-10? || ~11 Hz || Appears to mirror K4. Duty cycle 66.67%. Low on screen lock. Off until first interaction.
|-
| 6 || USB-C V+ || Supply power || || || || support fast charger : "normal mode = 5V+" "Fast changer = 12V+"
|-
| 7 || Unknown || Power supply? || ~3V-0V || None known || N/A || 0 when usb-c not plugged in, falls slowly on first interaction if USB-C plugged in. Power draw related?
|}

=== Cluster L ===

TODO: Update diagram

{| class=wikitable
! Pad # || Name || Type || Levels || Continuity || Frequency || Comment
|-
| 1 || Li-Ion Batt Vdd Mirror || Power Supply || Std. Li-Ion || || ||
|-
| 2 || GND || || || || ||
|-
| 3 || Li-Ion Batt Vdd || Battery Input || Std. Li-Ion || || ||
|-
| 4 || Mirrored Ground? || || || || || Holds steady @ 0, looks like a decoupled isolated ground
|-
| 5 || Battery pulse? || || || || <1 Hz || Duty cycle ~0%
|-
| 6 || GND || || || || ||
|}

Switch System Flaws

2019-02-19T13:24:22Z

Balika011: Fix broken changes...

Exploits are used to execute unofficial code (homebrew) on the Nintendo Switch. This page is a list of publicly known Switch system flaws.

For userland applications/applets flaws see [[Switch_Userland_Flaws|here]].

= System flaws =
== Hardware ==
Flaws in this category pertain to the underlying hardware that powers the Switch.

This includes components shared across Tegra based devices such as the [[TSEC]], the [[Security_Engine|Security Engine]], the [[GPU]] and so on.

{| class="wikitable" border="1"
! Summary
! Description
! Fixed with hardware model/revision
! Newest hardware model/revision this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| CVE-2018-6242 (leveraged by the ShofEL2 and Fusée Gelée exploits)
| The USB software stack provided inside the boot instruction rom (IROM/bootROM) contains a copy operation whose length can be controlled by an attacker. By carefully constructing a USB control request, an attacker can leverage this vulnerability to copy the contents of an attacker-controlled buffer over the active execution stack, gaining control of the Boot and Power Management processor (BPMP) before any lock-outs or privilege reductions occur. This execution can then be used to exfiltrate secrets and to load arbitrary code onto the main CPU Complex (CCPLEX) "application processors" at the highest possible level of privilege (typically as the TrustZone Secure Monitor at PL3/EL3).
| Unknown (Tegra186 and Tegra214)
| HAC-001 (Tegra210)
| January 2018
| April 23, 2018
| [[User:Shuffle2|shuffle2]] and fail0verflow (originally), [[User:Ktemkin|ktemkin]] and ReSwitched Team (independently), [[User:Naehrwert|naehrwert]] (independently), [[User:Hexkyz|hexkyz]] (independently), st4rk with [[User:Shinyquagsire23|Shiny Quagsire]] and Dazzozo (independently), and many others (independently).
|-
| GMMU DMA attack
| The Switch's GPU includes a separate MMU (GMMU) that is allowed to bypass the system's IOMMU (SMMU). By accessing the GPU's MMIO region and manipulating the page table entries in the GMMU, an attacker can read/write any portion of the DRAM (except memory carveouts).

[5.0.0+] Works around this hardware flaw by using memory pool partitioning. You can no longer escalate into sysmodules with GPU DMA because all their memory is allocated using heap that's carved out.
| None
| HAC-001 (Tegra210)
| Summer 2017
| December 28, 2017
| [[User:hexkyz|hexkyz]], [[User:SciresM|SciresM]] and [[User:qlutoo|qlutoo]]
|-
| Weak Security Engine context validation
| The Tegra X1 supports a "deep sleep" feature, where everything but DRAM and the PMC registers lose their content (and the SoC loses power). Upon awaking, the bootrom re-executes, restoring system state. Among these stored states is the Security Engine's saved state, which uses AES-128-CBC with a random key and all-zeroes IV. However, the bootrom doesn't perform a MAC on this data, and only validates the last block. This allows one to control most of security engine's state upon wakeup, if one has a way to modify the encrypted state buffer.

With a way to modify the encrypted state buffer, one can thus dump keys from "write-only" keyslots, etc.

This also bypasses the SBK protection of the bootROM: indeed, at warmboot, bootROM will always clear keyslot 0xE to prevent malicious code from saving the SBK. Moving the SBK to another keyslot in the saved context renders this protection moot.
| None
| HAC-001 (Tegra210)
| December 2017
| January 20, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]]
|-
| Security Engine keyslots vulnerable to partial overwrite attack
|
The Tegra X1 security engine supports writing keyslot data to the engine with syntax as follows:

SECURITY_ENGINE->AES_KEYTABLE_ADDR = (keyslot << 4) | (dword_index_in_keyslot);

SECURITY_ENGINE->AES_KEYTABLE_DATA = readle32(key, dword_index_in_keyslot * 4);

However, the Security Engine flushes writes to the internal key tables immediately when AES_KEYTABLE_DATA is written -- this allows one to overwrite a single dword of a key at a time, and thus brute force the contents of keyslots in time (2^32 * 8) = 2^35 instead of 2^256.
| None
| HAC-001 (Tegra210)
| Theorized Summer 2017 due to suggestive syntax, confirmed April 9, 2018
| April 9, 2018
| [[User:SciresM|SciresM]], almost surely others (independently).
|-
| Poor validation of bootrom SDRAM configuration parameters leads to arbitrary writes in bootrom
|
The Tegra X1 bootrom supports saving SDRAM parameters to scratch registers, and using the saved configuration to enable DRAM during warmboot.

The code that parses these parameters does if (params->EmcBctSpareN) *params->EmcBctSpareN = params->EmcBctSpareNPlusOne for most N, without validating either the address or value written to it.
There are other arbitrary writes in this code, as well (e.g. BootromPatch parameters intended for patching MISC registers do not check a relative offset to 0x7000000, etc).

This allows a user with access to the PMC registers (via pre-sleep bpmp execution, or otherwise) to gain arbitrary bootrom code execution.
| None
| HAC-001 (Tegra210)
| 2017
| December 16, 2018
| Everyone (independently).
|}

== Software ==
=== Bootloader ===
Flaws in this category pertain to any bootloader component such as the [[Package1#Package1ldr|package1ldr]], the [[Package1#Section_1|NX bootloader]] or the [[Package1#Section_0|warmboot binary]].

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Null-dereference in panic()
| The Switch's stage 1 bootloader, on panic(), clears the stack and then attempts to clear the Security Engine. However, it does so by dereferencing a pointer to the SE in .bss (initially NULL), and this pointer doesn't get initialized until partway into the bootloader's main() after several functions that might panic() are called. Thus, a panic() caused prior to SE initialization would result in the SE pointer still being NULL when dereferenced.
The BPMP doesn't have an active MPU and the bus won't data abort on an invalid address, so no exception will be entered: it'll end up overwriting some exception vectors with NULL before halting.

In 3.0.0, this was fixed by moving the security engine initialization earlier in main(), before the first function that could potentially panic().
| Some exception vectors overwritten with NULL, before SBK/other keyslots are cleared. Probably useless for anything more interesting.
| [[3.0.0]]
| [[3.0.0]]
| Early July, 2017
| July 30, 2017
| Everyone who diff'd 2.3.0 and 3.0.0 Package1
|-
| FUSE_DIS_PGM not written by package1
| The switch's hardware fuse driver contains a write-once bit in a register called "FUSE_DIS_PGM", which disables burning fuses until the next reboot. While Nintendo's bootloader code for waking up from sleep writes this on all firmware, the actual package1 initial bootloader forgets to write to it on cold reboot.

This isn't too big of a problem because another fuse is burnt on retail devices (production mode), which prevents burning *all* fuses other than ODM_RESERVED ones in hardware.

This was fixed in 3.0.0 by writing to the register on cold boot (although the write happens in TZ instead of package1 where it should take place, possibly to obfuscate the fact that they made this mistake).
| Burning arbitrary ODM reserved fuses with TZ code execution, which should never be possible for non-bootloader code.

Warning: one could irreparably brick one's console by playing with this.
| [[3.0.0]]
| [[3.0.0]]
| Late summer/early fall 2017
| December 31, 2017
| [[User:SciresM|SciresM]], [[User:motezazer|motezazer]]
|-
| TSEC firmware compromises itself
| Package1ldr loads a firmware blob into TSEC early on boot. This piece of code runs on the TSEC in Authenticated Mode and has the sole purpose of generating the per-console TSEC key (see [[Cryptosystem]]).

As a way to mitigate attacks, the TSEC firmware blob is split into 3 stages: [[TSEC#Stage_0|Stage 0]] which is unencrypted and unsigned, [[TSEC#Stage_1|Stage 1]] which is unencrypted but signed and [[TSEC#Stage_2|Stage 2]] which is encrypted and signed.
Stage 0 loads a static pre-generated signature into the Falcon's CPU crypto registers, loads Stage 1 into the Falcon's CODE region and jumps to it. Execution will proceed into Stage 1 in Authenticated Mode if, and only if, the loaded signature matches the one Falcon calculates internally for Stage 1.

Among various things, Stage 1 will attempt to do a "backwards" security check by calculating a CMAC over Stage 0 and comparing it with a known hash stored in the TSEC firmware's key data (a small buffer stored after Stage 0's code). If the hashes don't match, execution aborts.

Stage 1 stores the calculated Stage 0's CMAC in the stack, but forgets to clear it. Since the stack is located in Falcon's DATA region, loading the TSEC firmware blob and dumping the DATA region afterwards (via MMIO) will reveal the calculated hash.
This allows using Stage 1 as an oracle to generate a valid CMAC for arbitrary Stage 0 code. Replacing the CMAC in the TSEC firmware's key data region results in Stage 1 accepting any Stage 0 code, thus rendering this security measure useless.

Additionally, since signed Falcon code can't be revoked without an hardware revision, an attacker can always reuse the flawed Stage 1 code even if a fix is issued.
| Running TSEC firmware's Stage 1 in a user controlled environment. Mostly useless, but may aid in side-channel attacks.
| None
| [[5.0.2]]
| January 2018
| April 29, 2018
| [[User:Hexkyz|hexkyz]], probably others.
|-
| pk1ldrhax
| Package1ldr decrypts and verifies the keyblob inside of the current BCT in order to get the package1 key, and then uses the package1 key to decrypt package1. It then validates package1 before jumping to it by checking the PK11 magic number, and that the section sizes sum to the expected size (and are individually less than the expected size).

However, package1ldr does not actually validate the package1 key against a fixed vector (much like kernel9loader forgot to do so on the 3ds). This would normally not matter, as keyblobs are validated -- however, with bootrom code execution one can dump SBK and forge keyblobs, and thus control the package1 key.

Thus ('''in theory, but not in practice due to the size of the brute force required''') one can replace the package1 key with garbage, causing package1 to decrypt into garbage, and hope that this garbage passes validation checks and that package1ldr jumping into the garbage will do something useful.

This was fixed incidentally in [[6.2.0]], as pk1ldr does not use keyblob data to decrypt package1 any more.

| With a large enough brute force: arbitrary package1 code execution from coldboot.

However, a usable brute force is on the order of >= ~2^80, so '''this is almost certainly not actually usable in any meaningful context'''.
| [[6.2.0]]
| [[6.2.0]]
| Early 2017 (as soon as plaintext package1ldr was first dumped)
| November 20, 2018
| Everyone
|-
|}

=== TrustZone ===
Flaws in this category pertain exclusively to the [[Package1#Section_2|Secure Monitor]].

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Non-atomic mutexes
| When an [[SMC]] is called, TrustZone sets a global variable to mark that an SMC is in progress, so that two SMCs using shared resources (like the security engine) do not trample on one another. On 1.0.0, this global variable was written using non-atomic writes, and thus a race condition is possible.

However, the SMC handler enforces that all SMCs must be called from core #3, unless the top-level handler ID is 1 (SMCs internal to the kernel). Thus, the only SMCs that can be run side-by-side are [any userland smc] and smcGetRandomBytesForKernel, and this turns out to not really be abusable.
| Mostly useless. Maybe some oob-write into unused (and thus useless) memory if running smcGetRandomBytesForKernel and smcGetRandomBytesForUser at the same time.
| [[2.0.0]]
| [[2.0.0]]
| December 2017 (Probably earlier by others)
| January 18, 2018
| [[User:SciresM|SciresM]], probably others.
|-
| jamais vu (non-secure world access to PMC MMIO and pre-deep sleep firmware)
| On [[1.0.0]], one could map in the PMC registers in userland. In addition, [[AM_services|am]] ran a little-kernel based firmware on the BPMP at runtime. With code execution under am, one could modify the BPMP's little-kernel firmware to hook deep sleep entry, and modify TrustZone/Security engine state.

This was fixed in [[2.0.0]] by making the PMC secure-world only, blacklisting the BPMP's exception vectors from being mapped, and thoroughly checking for malicious behavior on deep sleep entry.
| Arbitrary TrustZone code execution.
| [[2.0.0]]
| [[2.0.0]]
| December, 2017
| January 20, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]]
|-
| Missed BPMP Exception Vector Writes
| Starting in [[2.0.0]], the BPMP is asleep at runtime, and is turned on by TrustZone during [[SMC|smcCpuSuspend]] in order to initiate the deep sleep process. When it does so, it is held in RESET, and TrustZone attempts to write to the BPMP exception vectors at 0x6000F200 to register EVP_RESET = lp0_entry_fw_crt0, and all other EVPs to a function that simply reboots. However, while they successfully write EVP_RESET, they miss all the other vectors, accidentally writing to the 0x6000F004-0x6000F020 region instead of the 0x6000F204-0x6000F220 region they want to write to. This results in all the exception vectors for the BPMP other than RESET being "undefined" (attacker controlled).

With some way of causing an exception vector to be taken at the right time, this would give pre-sleep code execution (and thus arbitrary TrustZone code execution, via the security engine flaw). However, none of the abort vectors are really triggerable, and interrupts are disabled for the BPMP when it is taken out of reset. Thus, this is useless in practice.

This was fixed in [[4.0.0]] by writing to the correct registers.
| Theoretically: Arbitrary TrustZone code execution. In practice: Useless.
| [[4.0.0]]
| [[4.0.0]]
| January, 2018
| February 23, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]], [[User:Naehrwert|naehrwert]], [[User:Hexkyz|hexkyz]], probably others, independently.
|-
|}

=== Kernel ===
Flaws in this category pertain exclusively to the [[Package2#Section_0|HorizonOS Kernel]].

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Syscall Infoleaks
| Many syscalls leaked kernel pointers on sad paths (for example svcSetHeapSize and svcQueryMemory), until they landed a bunch of fixes in 2.0.0.
| Nothing really.
| [[2.0.0]]
| [[2.0.0]]
|
|
| ?
|-
| svcWaitSynchronization/svcReplyAndReceive bad cleanup on error
| If there is a page fault when fetching handles from the userspace array, it cleans up by dereferencing all objects despite having only loaded first N. Allows the attacker to make arbitrary decrefs on any kernel synchronization object, and thus can be used to get UAF. Haven't actually been tried on real HW though, but should work (tm).
| Kernel code execution
| [[2.0.0]]
| [[2.0.0]]
|
| 24 April
| [[User:qlutoo|qlutoo]]
|-
| Bad irq_id check in CreateInterruptEvent
| CreateInterruptEvent syscall is designed to work only for irq_id >= 32. All irq_ids < 32 are "per-core" and reserved for kernel use (watchdog/scheduling/core communications).
On 1.0.0 you could supply irq_id < 32 and it would write outside the SharedIrqs table.
| You can register irq's in the Core3Irqs table, and thus register per-core irqs for core3, that are normally reserved for kernel. Useless.
| [[2.0.0]]
| [[2.0.0]]
| ~October
| 17 October
| [[User:qlutoo|qlutoo]]
|-
| Kernel .text mapped executable in usermode
| Prior to [[3.0.2]] the kernel .text was [[Memory_layout|mapped]] in usermode as executable. This can be used for usermode ROP for bypassing ASLR, but SVCs/IPC are not usable by running kernel .text in usermode.
| Executing kernel .text in usermode
| [[3.0.2]]
| [[3.0.2]]
|
| 34c3 (December 28, 2017)
| [[User:qlutoo|qlutoo]]
|-
| Memory Controller not properly secured
| The Switch OS originally had the memory controller not set to be accessible only by the secure-world, which was problematic because insecure access can compromise the kernel.

This was fixed partially in [[2.0.0]] by blacklisting the memory controller from being mapped by user-processes, and was fixed entirely in [[4.0.0]] by making the memory controller TZ-only and making all kernel accesses go through [[SMC|smcReadWriteRegister]].
| With some way to access the memory controller MMIO, arbitrary kernel code execution.
| [[4.0.0]]
| [[4.0.0]]
| January 2018
| January 2018
| [[User:SciresM|SciresM]], [[User:Yellows8|yellows8]]
|-
| Potential [[SVC|svcWaitForAddress]] thread use-after-free
| Between [[4.0.0]], where svcWaitForAddress was introduced, and [[7.0.0]], there was a second intrusive rbtree node in KThread for the WaitForAddress tree (the key being (address, priority), sorted lexicographically). Unlike the WaitProcessWideKeyAtomic tree, the kernel forgot to reinsert the WaitForAddress node when the thread's priority changed (priority inheritance and/or SetPriority), breaking the rbtree invariants; and since the kernel walks through the entire tree to remove intrusive nodes, you could cause threads to stay in the tree even after their deletion.

[[7.0.0]] fixed the issue by using the same intrusive node for both trees. The thread/node knows which tree it is in, and the latter is correctly updated when thread priority changes.
| It unluckily didn't look exploitable
| [[7.0.0]]
| [[7.0.0]]
| July 2018
| February 2019
| [[User:TuxSH|TuxSH]]
|-
|}

=== FIRM-package System Modules ===
Flaws in this category pertain to any of the [[Package2#Section_1|built-in system modules]].

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Service access control bypass (sm:h, smhax, probably other names)
| Prior to [[3.0.1]], the ''service manager'' (sm) built-in system module treats a user as though it has full permissions if the user creates a new "sm:" port session but bypasses [[Services_API#Initialize|initialization]]. This is due to the other sm commands skipping the service ACL check for Pids <= 7 (i.e. all kernel bundled modules) and that skipping the initialization command leaves the Pid field uninitialized.
In [[3.0.1]], sm returns error code 0x415 if [[Services_API#Initialize|Initialize]] has not been called yet.
| Acquiring, registering, and unregistering arbitrary services
| [[3.0.1]]
| [[3.0.1]]
| May 2017
| August 17, 2017
| Everyone
|-
| Overly permissive SPL service
| The concept behind the switch's [[SMC|Secure Monitor]] is that all cryptographic keydata is located in userspace, but stored as "access keys" encrypted with "keks" that never leave TrustZone. The [[SPL services|spl]] ("security processor liaison"?) service serves as an interface between the rest of the system and the secure monitor. Prior to [[4.0.0]], spl exposed only a single service "spl:", which provided all TrustZone wrapper functions to all sysmodules with access to it. Thus anyone with access to the spl: service (via smhax or by pwning a sysmodule with access) could do crypto with any access keys they knew.

This was fixed in [[4.0.0]] by splitting spl: into spl:, spl:mig, spl:ssl, spl:es, and spl:fs.
| Arbitrary spl: crypto with any access keys one knows. For example, one could use the SSL module's access keys to decrypt their console's SSL certificate private key without having to pwn the SSL sysmodule.
| [[4.0.0]]
| [[4.0.0]]
| Summer 2017 (after smhax was discovered).
| December 23, 2017
| Everyone
|-
| Single session services not really single session
| Several "critical" services (like fsp-ldr, fsp-pr, sm:m, etc) are meant to only ever hold a single session with a specific sysmodule. However, when a sysmodule dies, all its service session handles are released -- and thus killing the holder of a single session handle would allow one (via sm:hax etc) to get access to that service.

This was fixed in [[4.0.0]] by adding a semaphore to these critical single-session services, so that even if one gets access to them an error code will be returned when attempting to use any of their commands.
| With some way to access these services and kill their session holders (like expLDR): dumping sysmodule code, arbitrary service access, elevated filesystem permissions, etc.
| [[4.0.0]]
| [[4.0.0]]
| May/June 2017 (basically immediately after smhax was discovered)
| December 30, 2017
| Everyone
|-
| nspwn
| fsp-ldr command 0 "MountCode" takes in a Content Path (retrieved from NCM by Loader), and returns an IFileSystem for the resulting ExeFS. These content paths, are normally NCAs, but MountCode also supports a number of other formats, including ".nsp" -- which is just a PFS0.

When a path ending in ".nsp" is parsed by MountCode, the PFS0 is treated as a raw ExeFS. Because there is no NCA header, the ACID signatures are not validated -- and because there are no other signatures in a PFS0, this results in no signature checking happening at all.

The actual .nsp handling is eventually done by {content mounting function} called by MountCode and other FS commands.

Thus, by placing an ExeFS (NSOs + "main.npdm") and setting one's desired title ID to "@Sdcard:/some_title.nsp" or "@User:/some_title.nsp" etc one can launch arbitrary unsigned code, with arbitrary unsigned NPDMs.

This appears to have been fixed by only allowing .nsp when the input fstype==7 for the internal content-mounting function, returning 0x2EE202 otherwise.
| With access to "lr": Arbitrary code execution with full system privileges.
| [[5.0.0]]
| [[5.0.0]]
| Late 2017
| April 23, 2018
| Everyone
|-
| Single null-byte stack overflow in Loader ContentPath parsing
| Previously, loader content path parsing looked like this, where path_from_lr was up to 0x300 bytes and not necessarily null-terminated:

char nca_path[0x300] = {0};
strcat(nca_path, path_from_lr);
for (int i = 0; nca_path[i]; i++) {
if (nca_path[i] == '\\') { nca_path[i] = '/'); }
}

Thus, a content path of the maximum length (0x300 bytes) would result in strcat writing a NULL terminator past the end of the nca_path buffer.

This was fixed in [[6.0.0]], the new code looks like this:

char nca_path[0x300];
strncpy(nca_path, path_from_lr, sizeof(nca_path));
for (int i = 0; i < sizeof(nca_path) && nca_path[i]; i++) {
if (nca_path[i] == '\\') { nca_path[i] = '/'); }
}

| With access to "lr": single null-byte stack overflow in Loader. Maybe (but probably not) loader code execution.
| [[6.0.0]]
| [[6.0.0]]
| September 2, 2018
| September 19, 2018
| SciresM
|-
|}

=== System Modules ===
Flaws in this category pertain to any non-built-in system module.

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Out-of-bounds array read for [[BCAT_Content_Container]] secret-data index
| The [[BCAT_Content_Container]] secret-data index is not validated at all. This is handled before the RSA-signature(?) is ever used. Since the field is an u8, a total of 0x800-bytes relative to the array start can be accessed.
This is not useful since the string loaded from this array is only involved with key-generation.
|
| Unknown
| [[2.0.0]]
| August 4, 2017
| August 6, 2017
| [[User: shinyquagsire23|Shiny Quagsire]], [[User:Yellows8|yellows8]] (independently)
|-
| OOB Read in NS system module (pl:utoohax, pl:utonium, maybe other names)
| Prior to [[3.0.0]], pl:u (Shared Font services implemented in the NS sysmodule) service commands 1,2,3 took in a signed 32-bit index and returned that index of an array but did not check that index at all. This allowed for an arbitrary read within a 34-bit range (33-bit signed) from NS .bss. In [[3.0.0]], sending out of range indexes causes error code 0x60A to be returned.
| Dumping full NS .text, .rodata and .data, infoleak, etc
| [[3.0.0]]
| [[3.0.0]]
| April 2017
| On exploit's fix in [[3.0.0]]
| [[User:qlutoo|qlutoo]], ReSwitched Team (independently)
|-
| Unchecked domain ID in common IPC code
| Prior to [[2.0.0]], object IDs in [[IPC_Marshalling#Domain_message|domain messages]] are not bounds checked. This out-of-bounds read could be exploited to brute-force ASLR and get PC control in some services that support domain messages.
|
| [[2.0.0]]
| [[2.0.0]]
| ~July 2017
| 20 July 2017‎
| [[User:hthh|hthh]]
|-
| expLDR (sysmodule handle table exhaustion)
| Most sysmodules share common template code to handle IPC control messages. The command DuplicateSession (type 5 command 2)'s template code will abort() if it fails to duplicate a session's handle for the requester. Because many sysmodules have limited handle table size (smaller than the browser/other entrypoints), repeatedly requesting to duplicate one's session will cause the sysmodule to run out of handle table space and abort, causing the service to release all its handles cleanly.
| Sysmodule crashes. Most usefully, crashing ldr allows access to fsp-ldr and crashing pm allows access to fsp-pr. Useless after [[4.0.0]], which mitigated a number of single-session service access issues.
| Unfixed
| [[4.1.0]]
| 24 June 2017
| 8 March 2018
| [[User:daeken|daeken]]
|-
| Transfer Memory leak in nvservices system module
| The nvservices sysmodule does not clear most of its transfer memory prior to release.
| The calling process can read key bits of memory, including breaking ASLR (by revealing the image base) and exposing the address of other transfer memory to set up attacks. More details here: [https://daeken.svbtle.com/nintendo-switch-nvservices-info-leak transfermeme (nvservices info leak)] by [[User:daeken|daeken]]
| [[6.0.0]]
| [[6.0.0]]
| June 2017
| 16 October 2018
| [[User:qlutoo|qlutoo]] and [[User:hexkyz|hexkyz]],
[[User:daeken|daeken]] (independently)
|-
| OOB write in audio system module
| Prior to [[2.0.0]], the [[Audio_services#audout:u|AppendAudioOutBuffer]] and [[Audio_services#audin:u|AppendAudioInBuffer]] IPC commands would blindly increment the appended buffers' count while using said count value as an index to where the user data should be copied into. This resulted in an 0x28 bytes, user controlled, out-of-bounds memory write into the [[Audio_services|audio]] sysmodule's memory space.
Combined with the [[Audio_services#audout:u|GetReleasedAudioOutBuffer]] or [[Audio_services#audin:u|GetReleasedAudioInBuffer]] commands, this could also be used as an 8 byte infoleak.

In [[2.0.0]], the commands now return error code 0x1099 if the number of unreleased buffers exceeds 0x1F.
| Code execution under audio sysmodule
| [[2.0.0]]
| [[2.0.0]]
|
| November 2, 2018
| [[User:hexkyz|hexkyz]], probably others.
|-
| nvhax (memory corruption in nvservices system module)
| Prior to [[6.2.0]], the [[NV_services|nvservices]] ioctl [[NV_services#.2Fdev.2Fnvhost-ctrl-gpu|NVGPU_GPU_IOCTL_WAIT_FOR_PAUSE]] would take a single "pwarpstate" argument which would be interpreted by nvservices as a memory pointer for writing 2 "warpstate" structs (one for each Streaming Multiprocessor).
This resulted in nvservices attempting to blindly memcpy into this user supplied address and trigger a crash. However, if paired with an infoleak, this could be used to arbitrarily write 0x30 bytes anywhere in nvservices' memory space.
Additionally, the "warpstate" struct itself was never initialized, which means nvservices would leak the 0x30 bytes from the stack. By invoking other ioctls it was also possible to partially control the stack contents and achieve a usable arbitrary memory write primitive.

In [[6.2.0]], [[NV_services#.2Fdev.2Fnvhost-ctrl-gpu|NVGPU_GPU_IOCTL_WAIT_FOR_PAUSE]] now takes 2 inline "warpstate" structs instead of a "pwarpstate" pointer, thus effectively avoiding the bad memcpy.
| Code execution under nvservices sysmodule
| [[6.2.0]]
| [[6.2.0]]
| April 5, 2017
| November 24, 2018
| [[User:hexkyz|hexkyz]]
|-
| Infoleak in nvservices system module
| The [[NV_services|nvservices]] ioctl [[NV_services#NVMAP_IOC_ALLOC|NVMAP_IOC_ALLOC]] takes an optional argument "addr" which allows the calling process to pass a pointer to user allocated memory for backing a nvmap object. If "addr" is left as 0, nvservices uses the transfer memory region (donated by the user during initialization) instead, when allocating memory for the nvmap object.
By design, freeing the nvmap object by calling the ioctl [[NV_services#NVMAP_IOC_FREE|NVMAP_IOC_FREE]] returns, in its "refcount" argument, the user address previously supplied if the reference count reaches 0.
However, prior to [[6.2.0]], the case where the transfer memory region is used to allocate the nvmap object was not taken into account, thus resulting in [[NV_services#NVMAP_IOC_FREE|NVMAP_IOC_FREE]] leaking back an address from within the transfer memory region mapped in nvservices' memory space.

In [[6.2.0]], [[NV_services#NVMAP_IOC_FREE|NVMAP_IOC_FREE]] no longer returns the address when the transfer memory region is used instead of user supplied memory.
| Combined with other vulnerabilities: Defeating ASLR in nvservices sysmodule.
| [[6.2.0]]
| [[6.2.0]]
| April 2017
| November 24, 2018
| Everyone
|-
|}

Memory layout

2018-09-09T21:59:57Z

Balika011: /* BIT */

= Userspace =
The userspace virtual address space can be either 32 or 36 bits. [2.0.0+] introduced support for 38 bit address spaces.

There are two regions randomized and enforced by the kernel, each one with upper bits random and 2MB-aligned:
* ReservedHeapRegion, available from [[SVC#svcGetInfo]].
* ReservedMapRegion, available from [[SVC#svcGetInfo]].
* [2.0.0+] NewReservedMapRegion, available from [[SVC#svcGetInfo]].
* [2.0.0+] TlsIoRegion, not available to userspace.

The main binary is placed at an address that is provided to the kernel by Loader via [[SVC#svcCreateProcess]].

Typically on 2.0.0+ systems, the main binary region has randomness in bits 37-21.

For the stack mapping region, the userland randomizes a page-offset where to start inside the region. This adds some additional entropy.

Binaries mapped by RO are mapped randomly everywhere in the entire address space. The base address for each NRO has all bits randomized and are 4K-aligned. This means that typically, on 2.0.0+ systems, bits 37-12 of the NRO base address are random.

For all binaries(main area / NROs), the R-- section is always located immediately after R-X. The RW- section is always located immediately after the R-- section. Hence, there's no extra randomization / guard-pages for these sections.

On version [[1.0.0]], the initial binaries loaded into memory by the kernel always have the upper 32-bits as all-zero, so there are 6 fewer bits of layout randomization.

Binaries loaded within the main-binary-region are loaded into memory in the following order, immediately after each other, for the binaries which exist in [[ExeFS]]:
* rtld
* main
* subsdk*
* sdk

== ASLR Implementation ==
The kernel uses a MT19937 random number generator, seeded by a [[SMC#GetRandomBytes|smcGetRandomBytes]]
=== 1.0.0 ===

if (AddressSpaceType == 2) {
BaseAddr = 0x80000000; // 64-bit
RandomMax = 0x6400;
}
else {
BaseAddr = 0x40000000; // 32-bit
RandomMax = 0x200;
}

if (AddressSpaceType == 4) {
MapRegionSize = 0;
HeapRegionSize = 0x80000000;
}
else {
MapRegionSize = 0x40000000;
HeapRegionSize = 0x40000000;
}

if (EnableAslr) {
rnd0 = GetRandomRange(0, RandomMax) << 21;
rnd1 = GetRandomRange(0, RandomMax) << 21;
}
else {
rnd0 = rnd1 = 0;
}

this->MapBaseAddr = BaseAddr + min(rnd0, rnd1)
this->HeapRegionBaseAddr = this->MapBaseAddr + MapRegionSize + max(rnd0, rnd1) - min(rnd0, rnd1)

= Kernel =
For more details, see [[#Notes]]. Here comes a summary.

PXN bit is set in the MMU descriptor for userland code pages. This means that userland code pages are not executable in kernel mode (this is equivalent to SMEP on x86).

For userland pages, the kernel has same access as userland (either both are read-only or both are read-write). It does not have SMAP. The previous rule has one exception: pages that are mapped unreadable in usermode are still forced readable from kernelmode.

KASLR is being used since [[5.0.0]], but not before, with the following pseudocode (might contains some errors):

<code><pre>
DRAM crt0 mapping (ttbr1): offsets DRAM with (rand64ViaSmc() % 0x3FFF0 << 21), allocates exactly (end - _start) + 1GB.
This is a "linear" mapping. Permissions are set properly.

KERN_ADDRSPACE := [VA(_start) : min(0xFFFFFFFFFFE00000 - VA(_start), 0x40000000)]
DRAM_FROM_SECTION1 := DRAM[0x808cd000:] // 0x808cd000 corresponds to start of section1 (loaded INI1) data, reused later

/* Global Randomize range: 0xFFFFFF8000000000 to 0xFFFFFFFFFFE00000. */
/*
Randomize picks a random integer in ranges, clears as many low bits required,
then checks if the address is acceptable, if not it attempts to iterate through page table entries.

If it doesn't find anything, it picks another integer. In case of general failure, the whole operation
may be done from the start again (maybe ?).
*/

/* Core0 executes this big KASLR function, then powers on the other CPUs (?). */
MapPartially(RandomizeL1Boundary(DRAM, sizeof(DRAM)) -> DRAM_FROM_SECTION1: offsetof DRAM_FROM_SECTION1,

/* Randomize */
KERN_ADDRSPACE {
Randomize(IOAndInitialStacks, 0x2000000) {
Map(Randomize(UartA, 0x1000)) -> UartA,
GuardPage,
Map(Randomize(Gicd, 0x1000)) -> Gicd,
GuardPage,
Map(Randomize(Gicc, 0x1000)) -> Gicc,
ForEachCore {
GuardPage,
Map(Randomize(EntryThreadStack, 0x1000)) -> NextFreePage(),
GuardPage,
Map(Randomize(IdleSchedulerThreadStack, 0x1000)) -> NextFreePage(),
GuardPage,
Map(Randomize(EL1AbortStack, 0x1000)) -> NextFreePage(),
}
},

Randomize(KernelStacks, 0xE00000),
Map(Randomize(SlabHeaps, 0x7E9000, AFTER(VA(_end)) -> PA(_end)),
Randomize(Kip1DecompressionBuffer, 0x8000000), /* 128 MB VA range */
},

Map(RandomizePageBoundary(GuardPage + KCoreContext * 4)) -> NextFreePages(4)
</pre></code>

== 1.0.0 ==
{| class="wikitable" border="1"
|-
! Virtual || Physical || Size || Attributes || Permissions || Description
|-
| 0xFFFFFFFFBFC00000-0xFFFFFFFFBFC45FFF || 0x800A0000 || 0x46000 || 0x78B || R-X || Kernel .text
|-
| 0xFFFFFFFFBFC46000-0xFFFFFFFFBFC48FFF || 0x800E6000 || 0x3000 || 0x6000000000078B || R-- || Kernel .rodata
|-
| 0xFFFFFFFFBFC49000-0xFFFFFFFFBFC4FFFF || 0x800E9000 || 0x7000 || 0x6000000000070B || RW- || Kernel .data+.bss
|-
| 0xFFFFFFFFBFD72000-0xFFFFFFFFBFD72FFF || 0x6000F000 || 0x1000 || 0x60000000000607 || RW- || Exception vectors
|-
| 0xFFFFFFFFBFDB5000-0xFFFFFFFFBFDB5FFF || 0x60007000 || 0x1000 || 0x60000000000607 || RW- || Flow controller
|-
| 0xFFFFFFFFBFDB7000-0xFFFFFFFFBFDB7FFF || 0x60004000 || 0x1000 || 0x60000000000607 || RW- || Primary ICTLR
|-
| 0xFFFFFFFFBFDB9000-0xFFFFFFFFBFDB9FFF || 0x60001000 || 0x1000 || 0x60000000000607 || RW- || Resource Semaphore
|-
| 0xFFFFFFFFBFDBB000-0xFFFFFFFFBFDBBFFF || 0x70016000 || 0x2000 || 0x60000000000607 || RW- || ATOMICS
|-
| 0xFFFFFFFFBFDBE000-0xFFFFFFFFBFDBEFFF || 0x7000E000 || 0x1000 || 0x60000000000607 || RW- || PMC
|-
| 0xFFFFFFFFBFDC0000-0xFFFFFFFFBFDC0FFF || 0x60006000 || 0x1000 || 0x60000000000607 || RW- || Clock and reset
|-
| 0xFFFFFFFFBFDC2000-0xFFFFFFFFBFDC2FFF || 0x7001D000 || 0x1000 || 0x60000000000607 || RW- || MC1
|-
| 0xFFFFFFFFBFDC4000-0xFFFFFFFFBFDC4FFF || 0x7001C000 || 0x1000 || 0x60000000000607 || RW- || MC0
|-
| 0xFFFFFFFFBFDC6000-0xFFFFFFFFBFDC6FFF || 0x70019000 || 0x1000 || 0x60000000000607 || RW- || MC
|-
| 0xFFFFFFFFBFDC8000-0xFFFFFFFFBFDC8FFF || 0x70006000 || 0x1000 || 0x60000000000607 || RW- || UART-A
|-
| 0xFFFFFFFFBFDCA000-0xFFFFFFFFBFDCBFFF || 0x80060000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| 0xFFFFFFFFBFDCE000-0xFFFFFFFFBFDCFFFF || 0x80068000 || 0x2000 || 0x6000000000070B || RW- || Kernel main stack (cpu0)
|-
| 0xFFFFFFFFBFDD2000-0xFFFFFFFFBFDD2FFF || 0x80070000 || 0x1000 || 0x6000000000070B || RW- || Kernel runner stack (cpu0)
|-
| 0xFFFFFFFFBFDD4000-0xFFFFFFFFBFDD5FFF || 0x80062000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| 0xFFFFFFFFBFDD8000-0xFFFFFFFFBFDD9FFF || 0x8006A000 || 0x2000 || 0x6000000000070B || RW- || Kernel main stack (cpu1)
|-
| 0xFFFFFFFFBFDDC000-0xFFFFFFFFBFDDCFFF || 0x80071000 || 0x1000 || 0x6000000000070B || RW- || Kernel runner stack (cpu1)
|-
| 0xFFFFFFFFBFDDE000-0xFFFFFFFFBFDDFFFF || 0x80064000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| 0xFFFFFFFFBFDE2000-0xFFFFFFFFBFDE3FFF || 0x8006C000 || 0x2000 || 0x6000000000070B || RW- || Kernel main stack (cpu2)
|-
| 0xFFFFFFFFBFDE6000-0xFFFFFFFFBFDE6FFF || 0x80072000 || 0x1000 || 0x6000000000070B || RW- || Kernel runner stack (cpu2)
|-
| 0xFFFFFFFFBFDE8000-0xFFFFFFFFBFDE9FFF || 0x80066000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| 0xFFFFFFFFBFDEC000-0xFFFFFFFFBFDEDFFF || 0x8006E000 || 0x2000 || 0x6000000000070B || RW- || Kernel main stack (cpu3)
|-
| 0xFFFFFFFFBFDF0000-0xFFFFFFFFBFDF0FFF || 0x80073000 || 0x1000 || 0x6000000000070B || RW- || Kernel runner stack (cpu3)
|-
| 0xFFFFFFFFBFDFB000-0xFFFFFFFFBFDFBFFF || 0x50041000 || 0x1000 || 0x60000000000607 || RW- || ARM Interrupt Distributor
|-
| 0xFFFFFFFFBFDFD000-0xFFFFFFFFBFDFDFFF || 0x50042000 || 0x1000 || 0x60000000000607 || RW- || Interrupt Controller Physical CPU interface
|-
| 0xFFFFFFFFBFDF2000-0xFFFFFFFFBFDF3FFF || 0x80060000+(cpuid*0x2000) || 0x2000 || 0x6000000000070B || RW- ||
|-
| 0xFFFFFFFFBFDF6000-0xFFFFFFFFBFDF7FFF || 0x80068000+(cpuid*0x2000) || 0x2000 || 0x6000000000070B || RW- || Kernel main stack (per-core self-mirror)
|-
| 0xFFFFFFFFBFDFF000-0xFFFFFFFFBFDFFFFF || 0x80084000+(cpuid*0x1000) || 0x1000 || 0x6000000000070B || RW- || Kernel runner stack (per-core self-mirror)
|-
| 0xFFFFFFFE00000000-... || 0x80000000 || ... || 0x60000000000709 || RW- || Raw DRAM access
|}

== 2.0.0 ==
{| class="wikitable" border="1"
|-
! Cores || Virtual || Physical || Size || Attributes || Permissions || Description
|-
| All || 0xFFFFFFF7FFC00000-0xFFFFFFF7FFC62FFF || 0x800A0000 || 0x63000 || 0x78B || R-X || Kernel .text
|-
| All || 0xFFFFFFF7FFC63000-0xFFFFFFF7FFC65FFF || 0x80103000 || 0x3000 || 0x6000000000078B || R-- || Kernel .rodata
|-
| All || 0xFFFFFFF7FFC66000-0xFFFFFFF7FFC6EFFF || 0x80106000 || 0x9000 || 0x6000000000070B || RW- || Kernel .data+.bss
|-
| All || 0xFFFFFFF7FFDC0000-0xFFFFFFF7FFDC0FFF || 0x60006000 || 0x1000 || 0x60000000000607 || RW- || Clock and Reset
|-
| All || 0xFFFFFFF7FFDC2000-0xFFFFFFF7FFDC2FFF || 0x7001D000 || 0x1000 || 0x60000000000607 || RW- || MC1
|-
| All || 0xFFFFFFF7FFDC4000-0xFFFFFFF7FFDC4FFF || 0x7001C000 || 0x1000 || 0x60000000000607 || RW- || MC0
|-
| All || 0xFFFFFFF7FFDC6000-0xFFFFFFF7FFDC6FFF || 0x70019000 || 0x1000 || 0x60000000000607 || RW- || MC
|-
| All || 0xFFFFFFF7FFDC8000-0xFFFFFFF7FFDC8FFF || 0x70006000 || 0x1000 || 0x60000000000607 || RW- || UART-A
|-
| All || 0xFFFFFFF7FFDCA000-0xFFFFFFF7FFDCAFFF || 0x80060000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDCE000-0xFFFFFFF7FFDCEFFF || 0x80068000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDD2000-0xFFFFFFF7FFDD2FFF || 0x80070000 || 0x1000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDD4000-0xFFFFFFF7FFDD4FFF || 0x80062000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDD8000-0xFFFFFFF7FFDD8FFF || 0x8006A000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDDC000-0xFFFFFFF7FFDDCFFF || 0x80071000 || 0x1000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDDE000-0xFFFFFFF7FFDDEFFF || 0x80064000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDE2000-0xFFFFFFF7FFDE2FFF || 0x8006C000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDE6000-0xFFFFFFF7FFDE6FFF || 0x80072000 || 0x1000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDE8000-0xFFFFFFF7FFDE8FFF || 0x80066000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDEC000-0xFFFFFFF7FFDECFFF || 0x8006E000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDF0000-0xFFFFFFF7FFDF0FFF || 0x80073000 || 0x1000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDFB000-0xFFFFFFF7FFDFBFFF || 0x50041000 || 0x1000 || 0x60000000000607 || RW- || ARM Interrupt Distributor
|-
| All || 0xFFFFFFF7FFDFD000-0xFFFFFFF7FFDFDFFF || 0x50042000 || 0x1000 || 0x60000000000607 || RW- || Interrupt Controller Physical CPU interface
|-
| All || 0xFFFFFFF800000000-... || 0x80000000 || ... || 0x60000000000709 || RW- || Raw DRAM access
|}

== 3.0.0 ==
{| class="wikitable" border="1"
|-
! Cores || Virtual || Physical || Size || Attributes || Permissions || Description
|-
| All || 0xFFFFFFF7FFC00000-0xFFFFFFF7FFC4AFFF || 0x800A0000 || 0x4B000 || 0x78B || R-X || Kernel .text
|-
| All || 0xFFFFFFF7FFC4B000-0xFFFFFFF7FFC4DFFF || 0x800EB000 || 0x3000 || 0x6000000000078B || R-- || Kernel .rodata
|-
| All || 0xFFFFFFF7FFC4E000-0xFFFFFFF7FFC5AFFF || 0x800EE000 || 0xD000 || 0x6000000000070B || RW- || Kernel .data+.bss
|-
| All || 0xFFFFFFF7FFDAC000-0xFFFFFFF7FFDACFFF || 0x60006000 || 0x1000 || 0x60000000000607 || RW- || Clock and Reset
|-
| All || 0xFFFFFFF7FFDAE000-0xFFFFFFF7FFDAEFFF || 0x7001D000 || 0x1000 || 0x60000000000607 || RW- || MC1
|-
| All || 0xFFFFFFF7FFDB0000-0xFFFFFFF7FFDB0FFF || 0x7001C000 || 0x1000 || 0x60000000000607 || RW- || MC0
|-
| All || 0xFFFFFFF7FFDB2000-0xFFFFFFF7FFDB2FFF || 0x70019000 || 0x1000 || 0x60000000000607 || RW- || MC
|-
| All || 0xFFFFFFF7FFDB4000-0xFFFFFFF7FFDB4FFF || 0x70006000 || 0x1000 || 0x60000000000607 || RW- || UART-A
|-
| All || 0xFFFFFFF7FFDFB000-0xFFFFFFF7FFDFBFFF || 0x50041000 || 0x1000 || 0x60000000000607 || RW- || ARM Interrupt Distributor
|-
| All || 0xFFFFFFF7FFDFD000-0xFFFFFFF7FFDFDFFF || 0x50042000 || 0x1000 || 0x60000000000607 || RW- || Interrupt Controller Physical CPU interface
|}

== 4.0.0 ==
{| class="wikitable" border="1"
|-
! Cores || Virtual || Physical || Size || Attributes || Permissions || Description
|-
| All || 0xFFFFFFF7FFC00000-0xFFFFFFF7FFC50FFF || 0x800A0000 || 0x51000 || 0x4000000000078B || R-X || Kernel .text
|-
| All || 0xFFFFFFF7FFC51000-0xFFFFFFF7FFC53FFF || 0x800F1000 || 0x3000 || 0x6000000000078B || R-- || Kernel .rodata
|-
| All || 0xFFFFFFF7FFC54000-0xFFFFFFF7FFC61FFF || 0x800F4000 || 0xE000 || 0x6000000000070B || RW- || Kernel .data+.bss
|-
| All || 0xFFFFFFF7FFDAC000-0xFFFFFFF7FFDACFFF || 0x60006000 || 0x1000 || 0x60000000000607 || RW- || Clock and Reset
|-
| All || 0xFFFFFFF7FFDAE000-0xFFFFFFF7FFDAEFFF || 0x7001D000 || 0x1000 || 0x60000000000607 || RW- || MC1
|-
| All || 0xFFFFFFF7FFDB0000-0xFFFFFFF7FFDB0FFF || 0x7001C000 || 0x1000 || 0x60000000000607 || RW- || MC0
|-
| All || 0xFFFFFFF7FFDB2000-0xFFFFFFF7FFDB2FFF || 0x70019000 || 0x1000 || 0x60000000000607 || RW- || MC
|-
| All || 0xFFFFFFF7FFDB4000-0xFFFFFFF7FFDB4FFF || 0x70006000 || 0x1000 || 0x60000000000607 || RW- || UART-A
|-
| All || 0xFFFFFFF7FFDFB000-0xFFFFFFF7FFDFBFFF || 0x50041000 || 0x1000 || 0x60000000000607 || RW- || ARM Interrupt Distributor
|-
| All || 0xFFFFFFF7FFDFD000-0xFFFFFFF7FFDFDFFF || 0x50042000 || 0x1000 || 0x60000000000607 || RW- || Interrupt Controller Physical CPU interface
|}

The rest are are mapped to core-specific physaddrs, each one is 0x1000-bytes. Descriptor ORR-value = 0x6000000000070B.

{| class="wikitable" border="1"
|-
! Vmem
! Physmem
|-
| 0xFFFFFFF7FFDF7000
| <physaddr from vmem 0xFFFFFFF7FFDF6000> + 0x1000
|-
| 0xFFFFFFF7FFDF3000
| <physaddr from vmem 0xFFFFFFF7FFDF2000> + 0x1000
|-
| 0xFFFFFFF7FFDF6000
| 0x800XX000
|-
| 0xFFFFFFF7FFDF2000
| 0x800XX000
|-
| 0xFFFFFFF7FFDFF000
| 0x800XX000
|-
| 0xFFFFFFF7FFDF9000
| 0x800XX000
|}

= Secure Monitor =

Unless otherwise mentionned, block descriptors (in our case, the one uses for the DRAM identity mapping) are all ORRed by 0x401 and page descriptors by 0x403.

== [[1.0.0]] ==

{| class="wikitable" border="1"
|-
! Vmem
! Physmem
! Size
! Descriptor ORR-value
! Permissions
! Description
|-
| 0x1F0000000
| 0x50041000
| 0x1000
| 0x40000000000324
|
| ARM Interrupt Distributor
|-
| 0x1F0002000
| 0x50042000
| 0x1000
| 0x40000000000324
|
| Interrupt Controller Physical CPU Interface
|-
| 0x1F0005000
| 0x70006000
| 0x1000
| 0x40000000000324
|
| UART-A
|-
| 0x1F0007000
| 0x60006000
| 0x1000
| 0x40000000000324
|
| Clock and Reset
|-
| 0x1F0009000
| 0x7000E000
| 0x1000
| 0x40000000000304
|
| PMC
|-
| 0x1F000B000
| 0x60005000
| 0x1000
| 0x40000000000304
|
| TMR
|-
| 0x1F000D000
| 0x6000C000
| 0x1000
| 0x40000000000304
|
| System Registers
|-
| 0x1F000F000
| 0x70012000
| 0x2000
| 0x40000000000304
|
| SE
|-
| 0x1F0012000
| 0x700F0000
| 0x1000
| 0x40000000000304
|
| SYSCTR0
|-
| 0x1F0014000
| 0x70019000
| 0x1000
| 0x40000000000304
|
| MC
|-
| 0x1F0016000
| 0x7000F000
| 0x1000
| 0x40000000000304
|
| FUSE
|-
| 0x1F0018000
| 0x70000000
| 0x4000
| 0x40000000000304
|
| MISC
|-
| 0x1F001D000
| 0x60007000
| 0x1000
| 0x40000000000304
|
| Flow controller
|-
| 0x1F001F000
| 0x40002000
| 0x1000
| 0x40000000000304
|
| IRAM
|-
| 0x1F0021000
| 0x7000D000
| 0x1000
| 0x40000000000304
|
| I2C-5
|-
| 0x1F0023000
| 0x6000D000
| 0x1000
| 0x40000000000304
|
| GPIO-1
|-
| 0x1F0025000
| 0x7000C000
| 0x1000
| 0x40000000000304
|
| I2C
|-
| 0x1F0180000
| 0x40020000
| 0x10000
| 0x40000000000324
|
| IRAM
|-
| 0x1F01A0000
| 0x7C010000
| 0x10000
| 0x40000000000384
|
| TZRAM
|-
| 0x1F01C3000
| 0x80010000
| 0x10000
| 0x40000000000324
|
| EMEM
|-
| 0x1F01C2000
| 0x8000F000
| 0x1000
| 0x40000000000324
|
| EMEM
|-
| 0x1F01E0000
| 0x7C013000
| 0xB000
| 0x304
|
| TZRAM (Secure Monitor)
|-
| 0x1F01F0000
| 0x7C01E000
| 0x2000
| 0x304
|
| TZRAM (Secure Monitor and ARMv8 init)
|-
| 0x1F01F6000
| 0x7C01E000
| 0x1000
| 0x40000000000304
|
| TZRAM
|-
| 0x1F01F8000
| 0x7C01F000
| 0x1000
| 0x40000000000304
|
| TZRAM
|-
| 0x1F01FA000
| 0x7C010000
| 0x1000
| 0x304
|
| TZRAM (Secure Monitor exception vectors)
|-
| 0x1F01FC000
| 0x7C011000
| 0x1000
| 0x40000000000304
|
| TZRAM
|-
| 0x1F01FE000
| 0x7C012000
| 0x1000
| 0x40000000000304
|
| TZRAM
|}

== [[2.0.0]] ==

{| class="wikitable" border="1"
|-
! Vmem
! Physmem
! Size
! Descriptor ORR-value
! Permissions
! Description
|-
| 0x7C010000
| 0x7C010000
| 0x10000
| 0x300
|
| TZRAM
|-
| 0x40020000
| 0x40020000
| 0x20000
| 0x300
|
| iRAM-C
|-
| 0x1F0080000
| 0x50041000
| 0x1000
| 0x40000000000304
|
| ARM Interrupt Distributor
|-
| 0x1F0082000
| 0x50042000
| 0x2000
| 0x40000000000304
|
| Interrupt Controller Physical CPU interface
|-
| 0x1F0085000
| 0x70006000
| 0x1000
| 0x40000000000324
|
| UART-A
|-
| 0x1F0087000
| 0x60006000
| 0x1000
| 0x40000000000324
|
| Clock and Reset
|-
| 0x1F0089000
| 0x7000E000
| 0x1000
| 0x40000000000304
|
| PMC
|-
| 0x1F008B000
| 0x60005000
| 0x1000
| 0x40000000000304
|
| TMR
|-
| 0x1F008D000
| 0x6000C000
| 0x1000
| 0x40000000000304
|
| System Registers
|-
| 0x1F008F000
| 0x70012000
| 0x2000
| 0x40000000000304
|
| SE
|-
| 0x1F0092000
| 0x700F0000
| 0x1000
| 0x40000000000304
|
| SYSCTR0
|-
| 0x1F0094000
| 0x70019000
| 0x1000
| 0x40000000000304
|
| MC
|-
| 0x1F0096000
| 0x7000F000
| 0x1000
| 0x40000000000304
|
| FUSE (0x7000F800)
|-
| 0x1F0098000
| 0x70000000
| 0x4000
| 0x40000000000304
|
| MISC
|-
| 0x1F009D000
| 0x60007000
| 0x1000
| 0x40000000000304
|
| Flow Controller
|-
| 0x1F009F000
| 0x40002000
| 0x1000
| 0x40000000000304
|
| iRAM-A
|-
| 0x1F00A1000
| 0x7000D000
| 0x1000
| 0x40000000000304
|
| I2C5 - SPI 2B-6
|-
| 0x1F00A3000
| 0x6000D000
| 0x1000
| 0x40000000000304
|
| GPIO-1 - GPIO-8
|-
| 0x1F00A5000
| 0x7000C000
| 0x1000
| 0x40000000000304
|
| I2C-I2C4
|-
| 0x1F00A7000
| 0x6000F000
| 0x1000
| 0x40000000000304
|
| Exception vectors
|-
| 0x1F0180000
| 0x40020000
| 0x10000
| 0x40000000000324
|
| iRAM-C
|-
| 0x1F0190000
| 0x40003000
| 0x1000
| 0x40000000000324
|
| iRAM-A
|-
| 0x1F01A0000
| 0x7C010000
| 0x10000
| 0x40000000000380
|
| TZRAM
|-
| 0x1F01C3000
| 0x80010000
| 0x10000
| 0x40000000000324
|
| EMEM
|-
| 0x1F01C2000
| 0x8000F000
| 0x1000
| 0x40000000000324
|
| EMEM
|-
| 0x1F01E0000
| 0x7C013000
| 0xB000
| 0x300
|
| TZRAM (Secure Monitor)
|-
| 0x1F01F0000
| 0x7C01E000
| 0x2000
| 0x300
|
| TZRAM (Secure Monitor and ARMv8 init)
|-
| 0x1F01F4000
| <varies>
| 0x1000
| 0x40000000000320
|
| DRAM (SPL .bss buffer visible to the Security Engine)
|-
| 0x1F01F6000
| 0x7C01E000
| 0x1000
| 0x40000000000300
|
| TZRAM
|-
| 0x1F01F8000
| 0x7C01F000
| 0x1000
| 0x40000000000300
|
| TZRAM
|-
| 0x1F01FA000
| 0x7C010000
| 0x1000
| 0x300
|
| TZRAM (Secure Monitor exception vectors)
|-
| 0x1F01FC000
| 0x7C011000
| 0x1000
| 0x40000000000300
|
| TZRAM
|-
| 0x1F01FE000
| 0x7C012000
| 0x1000
| 0x40000000000300
|
| TZRAM
|}

== [[5.0.0]] ==
5.0.0 modified the address map to have separate .text, .rodata, and .rwdata segments, instead of a single RWX segment.

However, the .rodata and .rwdata segments are both (mistakenly?) mapped R-W.

Because the same L3 page is shared for all mappings, this required modifying segment layout significantly to prevent clashes.

{| class="wikitable" border="1"
|-
! Vmem
! Physmem
! Size
! Descriptor ORR-value
! Description
|-
| 0x7C010000
| 0x7C010000
| 0x10000
| 0x300
| TZRAM Identity RWX (for init)
|-
| 0x40020000
| 0x40020000
| 0x20000
| 0x300
| IRAM Identity RWX (for init)
|-
| 0x1F0080000
| 0x50041000
| 0x1000
| 0x40000000000304
| ARM Interrupt Distributor
|-
| 0x1F0082000
| 0x50042000
| 0x2000
| 0x40000000000304
| Interrupt Controller Physical CPU
|-
| 0x1F0085000
| 0x70006000
| 0x1000
| 0x40000000000324
| UART-A
|-
| 0x1F0087000
| 0x60006000
| 0x1000
| 0x40000000000324
| Clock and Reset
|-
| 0x1F0089000
| 0x7000E000
| 0x1000
| 0x40000000000304
| PMC
|-
| 0x1F008B000
| 0x60005000
| 0x1000
| 0x40000000000304
| Timers
|-
| 0x1F008D000
| 0x6000C000
| 0x1000
| 0x40000000000304
| System Registers
|-
| 0x1F008F000
| 0x70012000
| 0x2000
| 0x40000000000304
| Security Engine
|-
| 0x1F00AD000
| 0x70412000
| 0x2000
| 0x40000000000304
| Undocumented/Not Present (Security Engine for Mariko?)
|-
| 0x1F0092000
| 0x700F0000
| 0x1000
| 0x40000000000304
| SYSCTR0
|-
| 0x1F0094000
| 0x70019000
| 0x1000
| 0x40000000000304
| Memory Controller
|-
| 0x1F0096000
| 0x7000F000
| 0x1000
| 0x40000000000304
| Fuse Registers
|-
| 0x1F0098000
| 0x70000000
| 0x4000
| 0x40000000000304
| MISC Registers
|-
| 0x1F009D000
| 0x60007000
| 0x1000
| 0x40000000000304
| Flow Controller
|-
| 0x1F009F000
| 0x40002000
| 0x1000
| 0x40000000000304
| IRAM
|-
| 0x1F00A1000
| 0x7000D000
| 0x1000
| 0x40000000000304
| I2C-5
|-
| 0x1F00A3000
| 0x6000D000
| 0x1000
| 0x40000000000304
| GPIO-1
|-
| 0x1F00A5000
| 0x7000C000
| 0x1000
| 0x40000000000304
| I2C
|-
| 0x1F00A7000
| 0x6000F000
| 0x1000
| 0x40000000000304
| BPMP Exception Vectors
|-
| 0x1F00A9000
| 0x7001C000
| 0x1000
| 0x40000000000304
| MC0
|-
| 0x1F00AB000
| 0x7001D000
| 0x1000
| 0x40000000000304
| MC1
|-
| 0x1F0100000
| 0x7C010000
| 0x10000
| 0x40000000000380
| TZRAM (R-- for context save)
|-
| 0x1F0140000
| 0x7C012000
| 0x9000
| 0x300
| TZRAM (R-X .text)
|-
| 0x1F0149000
| 0x7C01B000
| 0x1000
| 0x40000000000300
| TZRAM (RW- .rodata)
|-
| 0x1F014A000
| 0x7C01C000
| 0x2000
| 0x40000000000300
| TZRAM (RW- .rwdata)
|-
| 0x1F01A0000
| 0x40020000
| 0x10000
| 0x40000000000324
| IRAM (RW- for context save)
|-
| 0x1F01B0000
| 0x40003000
| 0x1000
| 0x40000000000324
| IRAM (BPMP firmware destination)
|-
| 0x1F01C7000
| 0x8000F000
| 0x1000
| 0x40000000000324
| DRAM (SE Context Save destination)
|-
| 0x1F01E0000
| 0x7C010000
| 0x2000
| 0x300
| TZRAM (RWX pk2ldr for init)
|-
| 0x1F01F4000
| X
| 0x1000
| 0x40000000000723
| DRAM (SPL .bss buffer visible to the Security Engine)
|-
| 0x1F01F6000
| 0x7C010000
| 0x1000
| 0x40000000000300
| TZRAM (stacks)
|-
| 0x1F01F8000
| 0x7C011000
| 0x1000
| 0x40000000000300
| TZRAM (stacks)
|-
| 0x1F01FA000
| 0x7C01D000
| 0x1000
| 0x40000000000300
| TZRAM (stacks, warmboot crt0)
|-
| 0x1F01FC000
| 0x7C01E000
| 0x1000
| 0x40000000000300
| TZRAM (L2 Page Table)
|-
| 0x1F01FE000
| 0x7C01F000
| 0x1000
| 0x40000000000300
| TZRAM (L3 Page Table)
|-
|}

== [[6.0.0]] ==
6.0.0 reduced the .rwdata segment to one page (previously 2).

{| class="wikitable" border="1"
|-
! Vmem
! Physmem
! Size
! Descriptor ORR-value
! Description
|-
| 0x7C010000
| 0x7C010000
| 0x10000
| 0x300
| TZRAM Identity RWX (for init)
|-
| 0x40020000
| 0x40020000
| 0x20000
| 0x300
| IRAM Identity RWX (for init)
|-
| 0x1F0080000
| 0x50041000
| 0x1000
| 0x40000000000304
| ARM Interrupt Distributor
|-
| 0x1F0082000
| 0x50042000
| 0x2000
| 0x40000000000304
| Interrupt Controller Physical CPU
|-
| 0x1F0085000
| 0x70006000
| 0x1000
| 0x40000000000324
| UART-A
|-
| 0x1F0087000
| 0x60006000
| 0x1000
| 0x40000000000324
| Clock and Reset
|-
| 0x1F0089000
| 0x7000E000
| 0x1000
| 0x40000000000304
| PMC
|-
| 0x1F008B000
| 0x60005000
| 0x1000
| 0x40000000000304
| Timers
|-
| 0x1F008D000
| 0x6000C000
| 0x1000
| 0x40000000000304
| System Registers
|-
| 0x1F008F000
| 0x70012000
| 0x2000
| 0x40000000000304
| Security Engine
|-
| 0x1F00AD000
| 0x70412000
| 0x2000
| 0x40000000000304
| Undocumented/Not Present (Security Engine for Mariko?)
|-
| 0x1F0092000
| 0x700F0000
| 0x1000
| 0x40000000000304
| SYSCTR0
|-
| 0x1F0094000
| 0x70019000
| 0x1000
| 0x40000000000304
| Memory Controller
|-
| 0x1F0096000
| 0x7000F000
| 0x1000
| 0x40000000000304
| Fuse Registers
|-
| 0x1F0098000
| 0x70000000
| 0x4000
| 0x40000000000304
| MISC Registers
|-
| 0x1F009D000
| 0x60007000
| 0x1000
| 0x40000000000304
| Flow Controller
|-
| 0x1F009F000
| 0x40002000
| 0x1000
| 0x40000000000304
| IRAM
|-
| 0x1F00A1000
| 0x7000D000
| 0x1000
| 0x40000000000304
| I2C-5
|-
| 0x1F00A3000
| 0x6000D000
| 0x1000
| 0x40000000000304
| GPIO-1
|-
| 0x1F00A5000
| 0x7000C000
| 0x1000
| 0x40000000000304
| I2C
|-
| 0x1F00A7000
| 0x6000F000
| 0x1000
| 0x40000000000304
| BPMP Exception Vectors
|-
| 0x1F00A9000
| 0x7001C000
| 0x1000
| 0x40000000000304
| MC0
|-
| 0x1F00AB000
| 0x7001D000
| 0x1000
| 0x40000000000304
| MC1
|-
| 0x1F0100000
| 0x7C010000
| 0x10000
| 0x40000000000380
| TZRAM (R-- for context save)
|-
| 0x1F0140000
| 0x7C012000
| 0x9000
| 0x300
| TZRAM (R-X .text)
|-
| 0x1F0149000
| 0x7C01B000
| 0x1000
| 0x40000000000300
| TZRAM (RW- .rodata)
|-
| 0x1F014A000
| 0x7C01C000
| 0x1000
| 0x40000000000300
| TZRAM (RW- .rwdata)
|-
| 0x1F01A0000
| 0x40020000
| 0x10000
| 0x40000000000324
| IRAM (RW- for context save)
|-
| 0x1F01B0000
| 0x40003000
| 0x1000
| 0x40000000000324
| IRAM (BPMP firmware destination)
|-
| 0x1F01C7000
| 0x8000F000
| 0x1000
| 0x40000000000324
| DRAM (SE Context Save destination)
|-
| 0x1F01E0000
| 0x7C010000
| 0x2000
| 0x300
| TZRAM (RWX pk2ldr for init)
|-
| 0x1F01F4000
| X
| 0x1000
| 0x40000000000723
| DRAM (SPL .bss buffer visible to the Security Engine)
|-
| 0x1F01F6000
| 0x7C010000
| 0x1000
| 0x40000000000300
| TZRAM (stacks)
|-
| 0x1F01F8000
| 0x7C011000
| 0x1000
| 0x40000000000300
| TZRAM (stacks)
|-
| 0x1F01FA000
| 0x7C01D000
| 0x1000
| 0x40000000000300
| TZRAM (stacks, warmboot crt0)
|-
| 0x1F01FC000
| 0x7C01E000
| 0x1000
| 0x40000000000300
| TZRAM (L2 Page Table)
|-
| 0x1F01FE000
| 0x7C01F000
| 0x1000
| 0x40000000000300
| TZRAM (L3 Page Table)
|-
|}

= IRAM =
== BIT ==
During boot, the BootROM saves the BCT in IRAM at address 0x40000100. The preceding 0x100 bytes (IRAM memory range from 0x40000000 to 0x40000100) contain a structure called BIT (Boot Info Table) which encapsulates the BCT in IRAM and is initialized by the BootROM as follows:

{| class="wikitable" border="1"
|-
! Offset
! Size
! Field
! Description
|-
| 0x00
| 0x04
| br_version
| Set to 0x00210001 (BOOTDATA_VERSION_T210).
|-
| 0x04
| 0x04
| bd_version
| Set to 0x00210001 (BOOTDATA_VERSION_T210).
|-
| 0x08
| 0x04
| rcm_version
| Set to 0x00210001 (BOOTDATA_VERSION_T210).
|-
| 0x0C
| 0x04
| boot_type
|
BOOT_TYPE_COLD = 1
BOOT_TYPE_RECOVERY = 2
BOOT_TYPE_UART = 3
BOOT_TYPE_EXIT_RCM = 4
|-
| 0x10
| 0x04
| unk0
| Set to 0x05 on coldboot.
|-
| 0x14
| 0x04
| boot_device_type
|
|-
| 0x18
| 0x04
| boot_start_time
| Value from TIMERUS_CNTR_1US when the BootROM enters its main function.
|-
| 0x1C
| 0x04
| bootrom_lockdown_value
| This is the value that gets written into SB_CSR before nvboot. (0x10)
|-
| 0x20
| 0x04
| boot_read_bct_time
| Time spent reading the BCT.
|-
| 0x24
| 0x04
| boot_parse_bootloader_time
| Time spent parsing the bootloader info from the BCT.
|-
| 0x28
| 0x04
| osc_freq
| Value from CLK_RST_CONTROLLER_OSC_CTRL.
|-
| 0x2C
| 0x01
| is_boot_device_loaded
| Set to 1 after the boot device is initialized.
|-
| 0x2D
| 0x01
| is_sdram_configured
| Set to 1 after the SDRAM parameters are parsed.
|-
| 0x2E
| 0x01
| is_forced_rcm_pmc
| Set to 1 if bit 2 was set in APBDEV_PMC_SCRATCH0.
|-
| 0x2F
| 0x01
| is_enable_fail_back_pmc
| Set to 1 if bit 4 was set in APBDEV_PMC_SCRATCH0.
|-
| 0x30
| 0x02
| is_bootloader_version_mismatch
| Set to 1 if the bootloaders have different versions in the BCT.
|-
| 0x32
| 0x02
| is_bct_valid
| Set to 1 if the BCT was parsed successfully.
|-
| 0x34
| 0x04
| unk2
|
|-
| 0x38
| 0x04
| unk3
|
|-
| 0x3C
| 0x04
| active_bootloader_idx
| Value from 0 to 3 that represents which bootloader is active.
|-
| 0x40
| 0x04
| bct_start_block
| Block number where the BCT was found.
|-
| 0x44
| 0x04
| bct_start_page
| Page number where the BCT was found.
|-
| 0x48
| 0x04
| bct_size
| Size of the BCT in IRAM (0x2800).
|-
| 0x4C
| 0x04
| bct_ptr
| Pointer to the BCT in IRAM (0x40000100).
|-
| 0x50
| 0x18*4
| bootloader_headers[4]
|
{| class="wikitable" border="1"
|-
! Offset
! Size
! Field
|-
| 0x00
| 0x04
| is_active
|-
| 0x04
| 0x04
| bootloader_start_block
|-
| 0x08
| 0x04
| bootloader_start_page
|-
| 0x0C
| 0x04
| bootloader_length
|-
| 0x10
| 0x04
| bootloader_signed_start
|-
| 0x14
| 0x04
| bootloader_signature
|}
|-
| 0xB0
| 0x40
| boot_device_info
| Structure to hold boot device parameters.
|-
| 0xF0
| 0x04
| bct_end_ptr
| Pointer to the end of the BCT in IRAM (0x40002900).
|-
| 0xF4
| 0x0C
| padding
| Must be empty.
|}

= Notes =
== 2.0.0 ==
Granule size for TTBR0*_EL1 is 4KB.
TTBR0_EL1 vmem starts at vaddr 0x0.
vmem end-addr for TTBR1_EL1 is 0xffffffffffffffff. vmem start-addr for TTBR1_EL1 is 0xFFFFFFF000000000.
T0SZ = 31. Hence, bit-size of the TTBR0*_EL1 vmem region is 33. (0x0000000200000000)
T1SZ = 28. Hence, bit-size of the TTBR1*_EL1 vmem region is 36. (0x0000001000000000)

Note: ARM config for TTBR0 is presumably configured for userland later.

See arm-doc for "Table D4-25 Translation table entry addresses when using the 4KB translation granule".

See arm-doc for "Overview of VMSAv8-64 address translation using the 4KB translation granule".

See arm-doc for "Table D4-11 TCR.TnSZ values and IA ranges, 4K granule with no concatenation of tables".
Both TTBR*_EL1 use "Initial lookup level" 1. Therefore, the TTBR*_EL1 tables are level1.

Due to T*SZ, Stage1/Stage2 translation for the initial table(level1) are the same, except Stage2 uses hard-coded T0SZ.
Basically, the table is accessed as: ((u64*)tablebase)[<IA[y:30]>], where y = (37-T*SZ)+26. That is, starting at bit "y" ending(inclusive) at bit30. For TTBR0*_EL1, y = 32, while for TTBR1_EL1 y = 35.
Hence, for TTBR0, index=((vaddr>>30) & 0x7), and for TTBR1, index=((vaddr>>30) & 0x3f).

"Vector Base Address Register (EL1)" = 0xfffffff7ffc50800.

The table for TTBR0 only contains the following:
* Vmem 0x80000000 is mapped to physmem 0x80000000, using a size loaded from a register. This is only done when: "endaddr = 0x7fffffff + size; if(endaddr >= 0x80000001){...}"
** The size is loaded from: "(u32 *0x70019050 & 0x3fff) << 20;"
** The value written to the MMU-table descriptor is: "physaddr | val | 0x709;". val is 1<<52 when "tmp>>34" is non-zero and when "if((physaddr & 0x3c0000000) == 0)", otherwise val=0. tmp=size at the start and increased by 0xffffffffc0000000 each loop iteration. physaddr is increased by 0x40000000 each loop iteration.

TTBR1:
* vmem 0xFFFFFFF800000000 is mapped to physmem 0x80000000. Similar to above, except tmp=0 due to wrap-around, etc. This also has usermode/kernel XN enabled in the descriptor ORR-value. The chunksize used when increasing addr is 0xfffffff840000000, with another +=0x40000000 separate from the addr cmp for the loop.
** "endaddr = 0x3fffffff + (<size from above> | 0xfffffff800000000); enaddr = (endaddr & 0xffffffffc0000000)-1; if(endaddr >= 0xfffffff800000001){<map mem>}"

* Initializes level2 pagetable descriptor for vmem 0xFFFFFFF7C0000000. descriptor = 0x3 | physaddr. physaddr is core-specific.
* Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FFC00000. descriptor = 0x3 | physaddr. physaddr is core-specific.
* The content of the pagetable for the following level3 mmutables are not initialized in the main mmutable-init func. descriptor = 0x8007c003(0x3 | <physaddr tablebase>). tablebase=0x8007c000.
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FEE00000. physaddr = tablebase + (0x1<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF000000. physaddr = tablebase + (0x2<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF200000. physaddr = tablebase + (0x3<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FFA00000. physaddr = tablebase + (0x7<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FEC00000. physaddr = tablebase.
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF400000. physaddr = tablebase + (0x4<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF600000. physaddr = tablebase + (0x5<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF800000. physaddr = tablebase + (0x6<<12).

Memory layout

2018-09-03T19:19:15Z

Balika011: /* BIT, BCT */

= Userspace =
The userspace virtual address space can be either 32 or 36 bits. [2.0.0+] introduced support for 38 bit address spaces.

There are two regions randomized and enforced by the kernel, each one with upper bits random and 2MB-aligned:
* ReservedHeapRegion, available from [[SVC#svcGetInfo]].
* ReservedMapRegion, available from [[SVC#svcGetInfo]].
* [2.0.0+] NewReservedMapRegion, available from [[SVC#svcGetInfo]].
* [2.0.0+] TlsIoRegion, not available to userspace.

The main binary is placed at an address that is provided to the kernel by Loader via [[SVC#svcCreateProcess]].

Typically on 2.0.0+ systems, the main binary region has randomness in bits 37-21.

For the stack mapping region, the userland randomizes a page-offset where to start inside the region. This adds some additional entropy.

Binaries mapped by RO are mapped randomly everywhere in the entire address space. The base address for each NRO has all bits randomized and are 4K-aligned. This means that typically, on 2.0.0+ systems, bits 37-12 of the NRO base address are random.

For all binaries(main area / NROs), the R-- section is always located immediately after R-X. The RW- section is always located immediately after the R-- section. Hence, there's no extra randomization / guard-pages for these sections.

On version [[1.0.0]], the initial binaries loaded into memory by the kernel always have the upper 32-bits as all-zero, so there are 6 fewer bits of layout randomization.

Binaries loaded within the main-binary-region are loaded into memory in the following order, immediately after each other, for the binaries which exist in [[ExeFS]]:
* rtld
* main
* subsdk*
* sdk

== ASLR Implementation ==
The kernel uses a MT19937 random number generator, seeded by a [[SMC#GetRandomBytes|smcGetRandomBytes]]
=== 1.0.0 ===

if (AddressSpaceType == 2) {
BaseAddr = 0x80000000; // 64-bit
RandomMax = 0x6400;
}
else {
BaseAddr = 0x40000000; // 32-bit
RandomMax = 0x200;
}

if (AddressSpaceType == 4) {
MapRegionSize = 0;
HeapRegionSize = 0x80000000;
}
else {
MapRegionSize = 0x40000000;
HeapRegionSize = 0x40000000;
}

if (EnableAslr) {
rnd0 = GetRandomRange(0, RandomMax) << 21;
rnd1 = GetRandomRange(0, RandomMax) << 21;
}
else {
rnd0 = rnd1 = 0;
}

this->MapBaseAddr = BaseAddr + min(rnd0, rnd1)
this->HeapRegionBaseAddr = this->MapBaseAddr + MapRegionSize + max(rnd0, rnd1) - min(rnd0, rnd1)

= Kernel =
For more details, see [[#Notes]]. Here comes a summary.

PXN bit is set in the MMU descriptor for userland code pages. This means that userland code pages are not executable in kernel mode (this is equivalent to SMEP on x86).

For userland pages, the kernel has same access as userland (either both are read-only or both are read-write). It does not have SMAP. The previous rule has one exception: pages that are mapped unreadable in usermode are still forced readable from kernelmode.

KASLR is being used since [[5.0.0]], but not before, with the following pseudocode (might contains some errors):

<code><pre>
DRAM crt0 mapping (ttbr1): offsets DRAM with (rand64ViaSmc() % 0x3FFF0 << 21), allocates exactly (end - _start) + 1GB.
This is a "linear" mapping. Permissions are set properly.

KERN_ADDRSPACE := [VA(_start) : min(0xFFFFFFFFFFE00000 - VA(_start), 0x40000000)]
DRAM_FROM_SECTION1 := DRAM[0x808cd000:] // 0x808cd000 corresponds to start of section1 (loaded INI1) data, reused later

/* Global Randomize range: 0xFFFFFF8000000000 to 0xFFFFFFFFFFE00000. */
/*
Randomize picks a random integer in ranges, clears as many low bits required,
then checks if the address is acceptable, if not it attempts to iterate through page table entries.

If it doesn't find anything, it picks another integer. In case of general failure, the whole operation
may be done from the start again (maybe ?).
*/

/* Core0 executes this big KASLR function, then powers on the other CPUs (?). */
MapPartially(RandomizeL1Boundary(DRAM, sizeof(DRAM)) -> DRAM_FROM_SECTION1: offsetof DRAM_FROM_SECTION1,

/* Randomize */
KERN_ADDRSPACE {
Randomize(IOAndInitialStacks, 0x2000000) {
Map(Randomize(UartA, 0x1000)) -> UartA,
GuardPage,
Map(Randomize(Gicd, 0x1000)) -> Gicd,
GuardPage,
Map(Randomize(Gicc, 0x1000)) -> Gicc,
ForEachCore {
GuardPage,
Map(Randomize(EntryThreadStack, 0x1000)) -> NextFreePage(),
GuardPage,
Map(Randomize(IdleSchedulerThreadStack, 0x1000)) -> NextFreePage(),
GuardPage,
Map(Randomize(EL1AbortStack, 0x1000)) -> NextFreePage(),
}
},

Randomize(KernelStacks, 0xE00000),
Map(Randomize(SlabHeaps, 0x7E9000, AFTER(VA(_end)) -> PA(_end)),
Randomize(Kip1DecompressionBuffer, 0x8000000), /* 128 MB VA range */
},

Map(RandomizePageBoundary(GuardPage + KCoreContext * 4)) -> NextFreePages(4)
</pre></code>

== 1.0.0 ==
{| class="wikitable" border="1"
|-
! Virtual || Physical || Size || Attributes || Permissions || Description
|-
| 0xFFFFFFFFBFC00000-0xFFFFFFFFBFC45FFF || 0x800A0000 || 0x46000 || 0x78B || R-X || Kernel .text
|-
| 0xFFFFFFFFBFC46000-0xFFFFFFFFBFC48FFF || 0x800E6000 || 0x3000 || 0x6000000000078B || R-- || Kernel .rodata
|-
| 0xFFFFFFFFBFC49000-0xFFFFFFFFBFC4FFFF || 0x800E9000 || 0x7000 || 0x6000000000070B || RW- || Kernel .data+.bss
|-
| 0xFFFFFFFFBFD72000-0xFFFFFFFFBFD72FFF || 0x6000F000 || 0x1000 || 0x60000000000607 || RW- || Exception vectors
|-
| 0xFFFFFFFFBFDB5000-0xFFFFFFFFBFDB5FFF || 0x60007000 || 0x1000 || 0x60000000000607 || RW- || Flow controller
|-
| 0xFFFFFFFFBFDB7000-0xFFFFFFFFBFDB7FFF || 0x60004000 || 0x1000 || 0x60000000000607 || RW- || Primary ICTLR
|-
| 0xFFFFFFFFBFDB9000-0xFFFFFFFFBFDB9FFF || 0x60001000 || 0x1000 || 0x60000000000607 || RW- || Resource Semaphore
|-
| 0xFFFFFFFFBFDBB000-0xFFFFFFFFBFDBBFFF || 0x70016000 || 0x2000 || 0x60000000000607 || RW- || ATOMICS
|-
| 0xFFFFFFFFBFDBE000-0xFFFFFFFFBFDBEFFF || 0x7000E000 || 0x1000 || 0x60000000000607 || RW- || PMC
|-
| 0xFFFFFFFFBFDC0000-0xFFFFFFFFBFDC0FFF || 0x60006000 || 0x1000 || 0x60000000000607 || RW- || Clock and reset
|-
| 0xFFFFFFFFBFDC2000-0xFFFFFFFFBFDC2FFF || 0x7001D000 || 0x1000 || 0x60000000000607 || RW- || MC1
|-
| 0xFFFFFFFFBFDC4000-0xFFFFFFFFBFDC4FFF || 0x7001C000 || 0x1000 || 0x60000000000607 || RW- || MC0
|-
| 0xFFFFFFFFBFDC6000-0xFFFFFFFFBFDC6FFF || 0x70019000 || 0x1000 || 0x60000000000607 || RW- || MC
|-
| 0xFFFFFFFFBFDC8000-0xFFFFFFFFBFDC8FFF || 0x70006000 || 0x1000 || 0x60000000000607 || RW- || UART-A
|-
| 0xFFFFFFFFBFDCA000-0xFFFFFFFFBFDCBFFF || 0x80060000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| 0xFFFFFFFFBFDCE000-0xFFFFFFFFBFDCFFFF || 0x80068000 || 0x2000 || 0x6000000000070B || RW- || Kernel main stack (cpu0)
|-
| 0xFFFFFFFFBFDD2000-0xFFFFFFFFBFDD2FFF || 0x80070000 || 0x1000 || 0x6000000000070B || RW- || Kernel runner stack (cpu0)
|-
| 0xFFFFFFFFBFDD4000-0xFFFFFFFFBFDD5FFF || 0x80062000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| 0xFFFFFFFFBFDD8000-0xFFFFFFFFBFDD9FFF || 0x8006A000 || 0x2000 || 0x6000000000070B || RW- || Kernel main stack (cpu1)
|-
| 0xFFFFFFFFBFDDC000-0xFFFFFFFFBFDDCFFF || 0x80071000 || 0x1000 || 0x6000000000070B || RW- || Kernel runner stack (cpu1)
|-
| 0xFFFFFFFFBFDDE000-0xFFFFFFFFBFDDFFFF || 0x80064000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| 0xFFFFFFFFBFDE2000-0xFFFFFFFFBFDE3FFF || 0x8006C000 || 0x2000 || 0x6000000000070B || RW- || Kernel main stack (cpu2)
|-
| 0xFFFFFFFFBFDE6000-0xFFFFFFFFBFDE6FFF || 0x80072000 || 0x1000 || 0x6000000000070B || RW- || Kernel runner stack (cpu2)
|-
| 0xFFFFFFFFBFDE8000-0xFFFFFFFFBFDE9FFF || 0x80066000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| 0xFFFFFFFFBFDEC000-0xFFFFFFFFBFDEDFFF || 0x8006E000 || 0x2000 || 0x6000000000070B || RW- || Kernel main stack (cpu3)
|-
| 0xFFFFFFFFBFDF0000-0xFFFFFFFFBFDF0FFF || 0x80073000 || 0x1000 || 0x6000000000070B || RW- || Kernel runner stack (cpu3)
|-
| 0xFFFFFFFFBFDFB000-0xFFFFFFFFBFDFBFFF || 0x50041000 || 0x1000 || 0x60000000000607 || RW- || ARM Interrupt Distributor
|-
| 0xFFFFFFFFBFDFD000-0xFFFFFFFFBFDFDFFF || 0x50042000 || 0x1000 || 0x60000000000607 || RW- || Interrupt Controller Physical CPU interface
|-
| 0xFFFFFFFFBFDF2000-0xFFFFFFFFBFDF3FFF || 0x80060000+(cpuid*0x2000) || 0x2000 || 0x6000000000070B || RW- ||
|-
| 0xFFFFFFFFBFDF6000-0xFFFFFFFFBFDF7FFF || 0x80068000+(cpuid*0x2000) || 0x2000 || 0x6000000000070B || RW- || Kernel main stack (per-core self-mirror)
|-
| 0xFFFFFFFFBFDFF000-0xFFFFFFFFBFDFFFFF || 0x80084000+(cpuid*0x1000) || 0x1000 || 0x6000000000070B || RW- || Kernel runner stack (per-core self-mirror)
|-
| 0xFFFFFFFE00000000-... || 0x80000000 || ... || 0x60000000000709 || RW- || Raw DRAM access
|}

== 2.0.0 ==
{| class="wikitable" border="1"
|-
! Cores || Virtual || Physical || Size || Attributes || Permissions || Description
|-
| All || 0xFFFFFFF7FFC00000-0xFFFFFFF7FFC62FFF || 0x800A0000 || 0x63000 || 0x78B || R-X || Kernel .text
|-
| All || 0xFFFFFFF7FFC63000-0xFFFFFFF7FFC65FFF || 0x80103000 || 0x3000 || 0x6000000000078B || R-- || Kernel .rodata
|-
| All || 0xFFFFFFF7FFC66000-0xFFFFFFF7FFC6EFFF || 0x80106000 || 0x9000 || 0x6000000000070B || RW- || Kernel .data+.bss
|-
| All || 0xFFFFFFF7FFDC0000-0xFFFFFFF7FFDC0FFF || 0x60006000 || 0x1000 || 0x60000000000607 || RW- || Clock and Reset
|-
| All || 0xFFFFFFF7FFDC2000-0xFFFFFFF7FFDC2FFF || 0x7001D000 || 0x1000 || 0x60000000000607 || RW- || MC1
|-
| All || 0xFFFFFFF7FFDC4000-0xFFFFFFF7FFDC4FFF || 0x7001C000 || 0x1000 || 0x60000000000607 || RW- || MC0
|-
| All || 0xFFFFFFF7FFDC6000-0xFFFFFFF7FFDC6FFF || 0x70019000 || 0x1000 || 0x60000000000607 || RW- || MC
|-
| All || 0xFFFFFFF7FFDC8000-0xFFFFFFF7FFDC8FFF || 0x70006000 || 0x1000 || 0x60000000000607 || RW- || UART-A
|-
| All || 0xFFFFFFF7FFDCA000-0xFFFFFFF7FFDCAFFF || 0x80060000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDCE000-0xFFFFFFF7FFDCEFFF || 0x80068000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDD2000-0xFFFFFFF7FFDD2FFF || 0x80070000 || 0x1000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDD4000-0xFFFFFFF7FFDD4FFF || 0x80062000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDD8000-0xFFFFFFF7FFDD8FFF || 0x8006A000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDDC000-0xFFFFFFF7FFDDCFFF || 0x80071000 || 0x1000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDDE000-0xFFFFFFF7FFDDEFFF || 0x80064000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDE2000-0xFFFFFFF7FFDE2FFF || 0x8006C000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDE6000-0xFFFFFFF7FFDE6FFF || 0x80072000 || 0x1000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDE8000-0xFFFFFFF7FFDE8FFF || 0x80066000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDEC000-0xFFFFFFF7FFDECFFF || 0x8006E000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDF0000-0xFFFFFFF7FFDF0FFF || 0x80073000 || 0x1000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDFB000-0xFFFFFFF7FFDFBFFF || 0x50041000 || 0x1000 || 0x60000000000607 || RW- || ARM Interrupt Distributor
|-
| All || 0xFFFFFFF7FFDFD000-0xFFFFFFF7FFDFDFFF || 0x50042000 || 0x1000 || 0x60000000000607 || RW- || Interrupt Controller Physical CPU interface
|-
| All || 0xFFFFFFF800000000-... || 0x80000000 || ... || 0x60000000000709 || RW- || Raw DRAM access
|}

== 3.0.0 ==
{| class="wikitable" border="1"
|-
! Cores || Virtual || Physical || Size || Attributes || Permissions || Description
|-
| All || 0xFFFFFFF7FFC00000-0xFFFFFFF7FFC4AFFF || 0x800A0000 || 0x4B000 || 0x78B || R-X || Kernel .text
|-
| All || 0xFFFFFFF7FFC4B000-0xFFFFFFF7FFC4DFFF || 0x800EB000 || 0x3000 || 0x6000000000078B || R-- || Kernel .rodata
|-
| All || 0xFFFFFFF7FFC4E000-0xFFFFFFF7FFC5AFFF || 0x800EE000 || 0xD000 || 0x6000000000070B || RW- || Kernel .data+.bss
|-
| All || 0xFFFFFFF7FFDAC000-0xFFFFFFF7FFDACFFF || 0x60006000 || 0x1000 || 0x60000000000607 || RW- || Clock and Reset
|-
| All || 0xFFFFFFF7FFDAE000-0xFFFFFFF7FFDAEFFF || 0x7001D000 || 0x1000 || 0x60000000000607 || RW- || MC1
|-
| All || 0xFFFFFFF7FFDB0000-0xFFFFFFF7FFDB0FFF || 0x7001C000 || 0x1000 || 0x60000000000607 || RW- || MC0
|-
| All || 0xFFFFFFF7FFDB2000-0xFFFFFFF7FFDB2FFF || 0x70019000 || 0x1000 || 0x60000000000607 || RW- || MC
|-
| All || 0xFFFFFFF7FFDB4000-0xFFFFFFF7FFDB4FFF || 0x70006000 || 0x1000 || 0x60000000000607 || RW- || UART-A
|-
| All || 0xFFFFFFF7FFDFB000-0xFFFFFFF7FFDFBFFF || 0x50041000 || 0x1000 || 0x60000000000607 || RW- || ARM Interrupt Distributor
|-
| All || 0xFFFFFFF7FFDFD000-0xFFFFFFF7FFDFDFFF || 0x50042000 || 0x1000 || 0x60000000000607 || RW- || Interrupt Controller Physical CPU interface
|}

== 4.0.0 ==
{| class="wikitable" border="1"
|-
! Cores || Virtual || Physical || Size || Attributes || Permissions || Description
|-
| All || 0xFFFFFFF7FFC00000-0xFFFFFFF7FFC50FFF || 0x800A0000 || 0x51000 || 0x4000000000078B || R-X || Kernel .text
|-
| All || 0xFFFFFFF7FFC51000-0xFFFFFFF7FFC53FFF || 0x800F1000 || 0x3000 || 0x6000000000078B || R-- || Kernel .rodata
|-
| All || 0xFFFFFFF7FFC54000-0xFFFFFFF7FFC61FFF || 0x800F4000 || 0xE000 || 0x6000000000070B || RW- || Kernel .data+.bss
|-
| All || 0xFFFFFFF7FFDAC000-0xFFFFFFF7FFDACFFF || 0x60006000 || 0x1000 || 0x60000000000607 || RW- || Clock and Reset
|-
| All || 0xFFFFFFF7FFDAE000-0xFFFFFFF7FFDAEFFF || 0x7001D000 || 0x1000 || 0x60000000000607 || RW- || MC1
|-
| All || 0xFFFFFFF7FFDB0000-0xFFFFFFF7FFDB0FFF || 0x7001C000 || 0x1000 || 0x60000000000607 || RW- || MC0
|-
| All || 0xFFFFFFF7FFDB2000-0xFFFFFFF7FFDB2FFF || 0x70019000 || 0x1000 || 0x60000000000607 || RW- || MC
|-
| All || 0xFFFFFFF7FFDB4000-0xFFFFFFF7FFDB4FFF || 0x70006000 || 0x1000 || 0x60000000000607 || RW- || UART-A
|-
| All || 0xFFFFFFF7FFDFB000-0xFFFFFFF7FFDFBFFF || 0x50041000 || 0x1000 || 0x60000000000607 || RW- || ARM Interrupt Distributor
|-
| All || 0xFFFFFFF7FFDFD000-0xFFFFFFF7FFDFDFFF || 0x50042000 || 0x1000 || 0x60000000000607 || RW- || Interrupt Controller Physical CPU interface
|}

The rest are are mapped to core-specific physaddrs, each one is 0x1000-bytes. Descriptor ORR-value = 0x6000000000070B.

{| class="wikitable" border="1"
|-
! Vmem
! Physmem
|-
| 0xFFFFFFF7FFDF7000
| <physaddr from vmem 0xFFFFFFF7FFDF6000> + 0x1000
|-
| 0xFFFFFFF7FFDF3000
| <physaddr from vmem 0xFFFFFFF7FFDF2000> + 0x1000
|-
| 0xFFFFFFF7FFDF6000
| 0x800XX000
|-
| 0xFFFFFFF7FFDF2000
| 0x800XX000
|-
| 0xFFFFFFF7FFDFF000
| 0x800XX000
|-
| 0xFFFFFFF7FFDF9000
| 0x800XX000
|}

= Secure Monitor =

Unless otherwise mentionned, block descriptors (in our case, the one uses for the DRAM identity mapping) are all ORRed by 0x401 and page descriptors by 0x403.

== [[1.0.0]] ==

{| class="wikitable" border="1"
|-
! Vmem
! Physmem
! Size
! Descriptor ORR-value
! Permissions
! Description
|-
| 0x1F0000000
| 0x50041000
| 0x1000
| 0x40000000000324
|
| ARM Interrupt Distributor
|-
| 0x1F0002000
| 0x50042000
| 0x1000
| 0x40000000000324
|
| Interrupt Controller Physical CPU Interface
|-
| 0x1F0005000
| 0x70006000
| 0x1000
| 0x40000000000324
|
| UART-A
|-
| 0x1F0007000
| 0x60006000
| 0x1000
| 0x40000000000324
|
| Clock and Reset
|-
| 0x1F0009000
| 0x7000E000
| 0x1000
| 0x40000000000304
|
| PMC
|-
| 0x1F000B000
| 0x60005000
| 0x1000
| 0x40000000000304
|
| TMR
|-
| 0x1F000D000
| 0x6000C000
| 0x1000
| 0x40000000000304
|
| System Registers
|-
| 0x1F000F000
| 0x70012000
| 0x2000
| 0x40000000000304
|
| SE
|-
| 0x1F0012000
| 0x700F0000
| 0x1000
| 0x40000000000304
|
| SYSCTR0
|-
| 0x1F0014000
| 0x70019000
| 0x1000
| 0x40000000000304
|
| MC
|-
| 0x1F0016000
| 0x7000F000
| 0x1000
| 0x40000000000304
|
| FUSE
|-
| 0x1F0018000
| 0x70000000
| 0x4000
| 0x40000000000304
|
| MISC
|-
| 0x1F001D000
| 0x60007000
| 0x1000
| 0x40000000000304
|
| Flow controller
|-
| 0x1F001F000
| 0x40002000
| 0x1000
| 0x40000000000304
|
| IRAM
|-
| 0x1F0021000
| 0x7000D000
| 0x1000
| 0x40000000000304
|
| I2C-5
|-
| 0x1F0023000
| 0x6000D000
| 0x1000
| 0x40000000000304
|
| GPIO-1
|-
| 0x1F0025000
| 0x7000C000
| 0x1000
| 0x40000000000304
|
| I2C
|-
| 0x1F0180000
| 0x40020000
| 0x10000
| 0x40000000000324
|
| IRAM
|-
| 0x1F01A0000
| 0x7C010000
| 0x10000
| 0x40000000000384
|
| TZRAM
|-
| 0x1F01C3000
| 0x80010000
| 0x10000
| 0x40000000000324
|
| EMEM
|-
| 0x1F01C2000
| 0x8000F000
| 0x1000
| 0x40000000000324
|
| EMEM
|-
| 0x1F01E0000
| 0x7C013000
| 0xB000
| 0x304
|
| TZRAM (Secure Monitor)
|-
| 0x1F01F0000
| 0x7C01E000
| 0x2000
| 0x304
|
| TZRAM (Secure Monitor and ARMv8 init)
|-
| 0x1F01F6000
| 0x7C01E000
| 0x1000
| 0x40000000000304
|
| TZRAM
|-
| 0x1F01F8000
| 0x7C01F000
| 0x1000
| 0x40000000000304
|
| TZRAM
|-
| 0x1F01FA000
| 0x7C010000
| 0x1000
| 0x304
|
| TZRAM (Secure Monitor exception vectors)
|-
| 0x1F01FC000
| 0x7C011000
| 0x1000
| 0x40000000000304
|
| TZRAM
|-
| 0x1F01FE000
| 0x7C012000
| 0x1000
| 0x40000000000304
|
| TZRAM
|}

== [[2.0.0]] ==

{| class="wikitable" border="1"
|-
! Vmem
! Physmem
! Size
! Descriptor ORR-value
! Permissions
! Description
|-
| 0x7C010000
| 0x7C010000
| 0x10000
| 0x300
|
| TZRAM
|-
| 0x40020000
| 0x40020000
| 0x20000
| 0x300
|
| iRAM-C
|-
| 0x1F0080000
| 0x50041000
| 0x1000
| 0x40000000000304
|
| ARM Interrupt Distributor
|-
| 0x1F0082000
| 0x50042000
| 0x2000
| 0x40000000000304
|
| Interrupt Controller Physical CPU interface
|-
| 0x1F0085000
| 0x70006000
| 0x1000
| 0x40000000000324
|
| UART-A
|-
| 0x1F0087000
| 0x60006000
| 0x1000
| 0x40000000000324
|
| Clock and Reset
|-
| 0x1F0089000
| 0x7000E000
| 0x1000
| 0x40000000000304
|
| PMC
|-
| 0x1F008B000
| 0x60005000
| 0x1000
| 0x40000000000304
|
| TMR
|-
| 0x1F008D000
| 0x6000C000
| 0x1000
| 0x40000000000304
|
| System Registers
|-
| 0x1F008F000
| 0x70012000
| 0x2000
| 0x40000000000304
|
| SE
|-
| 0x1F0092000
| 0x700F0000
| 0x1000
| 0x40000000000304
|
| SYSCTR0
|-
| 0x1F0094000
| 0x70019000
| 0x1000
| 0x40000000000304
|
| MC
|-
| 0x1F0096000
| 0x7000F000
| 0x1000
| 0x40000000000304
|
| FUSE (0x7000F800)
|-
| 0x1F0098000
| 0x70000000
| 0x4000
| 0x40000000000304
|
| MISC
|-
| 0x1F009D000
| 0x60007000
| 0x1000
| 0x40000000000304
|
| Flow Controller
|-
| 0x1F009F000
| 0x40002000
| 0x1000
| 0x40000000000304
|
| iRAM-A
|-
| 0x1F00A1000
| 0x7000D000
| 0x1000
| 0x40000000000304
|
| I2C5 - SPI 2B-6
|-
| 0x1F00A3000
| 0x6000D000
| 0x1000
| 0x40000000000304
|
| GPIO-1 - GPIO-8
|-
| 0x1F00A5000
| 0x7000C000
| 0x1000
| 0x40000000000304
|
| I2C-I2C4
|-
| 0x1F00A7000
| 0x6000F000
| 0x1000
| 0x40000000000304
|
| Exception vectors
|-
| 0x1F0180000
| 0x40020000
| 0x10000
| 0x40000000000324
|
| iRAM-C
|-
| 0x1F0190000
| 0x40003000
| 0x1000
| 0x40000000000324
|
| iRAM-A
|-
| 0x1F01A0000
| 0x7C010000
| 0x10000
| 0x40000000000380
|
| TZRAM
|-
| 0x1F01C3000
| 0x80010000
| 0x10000
| 0x40000000000324
|
| EMEM
|-
| 0x1F01C2000
| 0x8000F000
| 0x1000
| 0x40000000000324
|
| EMEM
|-
| 0x1F01E0000
| 0x7C013000
| 0xB000
| 0x300
|
| TZRAM (Secure Monitor)
|-
| 0x1F01F0000
| 0x7C01E000
| 0x2000
| 0x300
|
| TZRAM (Secure Monitor and ARMv8 init)
|-
| 0x1F01F4000
| <varies>
| 0x1000
| 0x40000000000320
|
| DRAM (SPL .bss buffer visible to the Security Engine)
|-
| 0x1F01F6000
| 0x7C01E000
| 0x1000
| 0x40000000000300
|
| TZRAM
|-
| 0x1F01F8000
| 0x7C01F000
| 0x1000
| 0x40000000000300
|
| TZRAM
|-
| 0x1F01FA000
| 0x7C010000
| 0x1000
| 0x300
|
| TZRAM (Secure Monitor exception vectors)
|-
| 0x1F01FC000
| 0x7C011000
| 0x1000
| 0x40000000000300
|
| TZRAM
|-
| 0x1F01FE000
| 0x7C012000
| 0x1000
| 0x40000000000300
|
| TZRAM
|}

== [[5.0.0]] ==
5.0.0 modified the address map to have separate .text, .rodata, and .rwdata segments, instead of a single RWX segment.

However, the .rodata and .rwdata segments are both (mistakenly?) mapped R-W.

Because the same L3 page is shared for all mappings, this required modifying segment layout significantly to prevent clashes.

{| class="wikitable" border="1"
|-
! Vmem
! Physmem
! Size
! Descriptor ORR-value
! Description
|-
| 0x7C010000
| 0x7C010000
| 0x10000
| 0x300
| TZRAM Identity RWX (for init)
|-
| 0x40020000
| 0x40020000
| 0x20000
| 0x300
| IRAM Identity RWX (for init)
|-
| 0x1F0080000
| 0x50041000
| 0x1000
| 0x40000000000304
| ARM Interrupt Distributor
|-
| 0x1F0082000
| 0x50042000
| 0x2000
| 0x40000000000304
| Interrupt Controller Physical CPU
|-
| 0x1F0085000
| 0x70006000
| 0x1000
| 0x40000000000324
| UART-A
|-
| 0x1F0087000
| 0x60006000
| 0x1000
| 0x40000000000324
| Clock and Reset
|-
| 0x1F0089000
| 0x7000E000
| 0x1000
| 0x40000000000304
| PMC
|-
| 0x1F008B000
| 0x60005000
| 0x1000
| 0x40000000000304
| Timers
|-
| 0x1F008D000
| 0x6000C000
| 0x1000
| 0x40000000000304
| System Registers
|-
| 0x1F008F000
| 0x70012000
| 0x2000
| 0x40000000000304
| Security Engine
|-
| 0x1F00AD000
| 0x70412000
| 0x2000
| 0x40000000000304
| Undocumented/Not Present (Security Engine for Mariko?)
|-
| 0x1F0092000
| 0x700F0000
| 0x1000
| 0x40000000000304
| SYSCTR0
|-
| 0x1F0094000
| 0x70019000
| 0x1000
| 0x40000000000304
| Memory Controller
|-
| 0x1F0096000
| 0x7000F000
| 0x1000
| 0x40000000000304
| Fuse Registers
|-
| 0x1F0098000
| 0x70000000
| 0x4000
| 0x40000000000304
| MISC Registers
|-
| 0x1F009D000
| 0x60007000
| 0x1000
| 0x40000000000304
| Flow Controller
|-
| 0x1F009F000
| 0x40002000
| 0x1000
| 0x40000000000304
| IRAM
|-
| 0x1F00A1000
| 0x7000D000
| 0x1000
| 0x40000000000304
| I2C-5
|-
| 0x1F00A3000
| 0x6000D000
| 0x1000
| 0x40000000000304
| GPIO-1
|-
| 0x1F00A5000
| 0x7000C000
| 0x1000
| 0x40000000000304
| I2C
|-
| 0x1F00A7000
| 0x6000F000
| 0x1000
| 0x40000000000304
| BPMP Exception Vectors
|-
| 0x1F00A9000
| 0x7001C000
| 0x1000
| 0x40000000000304
| MC0
|-
| 0x1F00AB000
| 0x7001D000
| 0x1000
| 0x40000000000304
| MC1
|-
| 0x1F0100000
| 0x7C010000
| 0x10000
| 0x40000000000380
| TZRAM (R-- for context save)
|-
| 0x1F0140000
| 0x7C012000
| 0x9000
| 0x300
| TZRAM (R-X .text)
|-
| 0x1F0149000
| 0x7C01B000
| 0x1000
| 0x40000000000300
| TZRAM (RW- .rodata)
|-
| 0x1F014A000
| 0x7C01C000
| 0x2000
| 0x40000000000300
| TZRAM (RW- .rwdata)
|-
| 0x1F01A0000
| 0x40020000
| 0x10000
| 0x40000000000324
| IRAM (RW- for context save)
|-
| 0x1F01B0000
| 0x40003000
| 0x1000
| 0x40000000000324
| IRAM (BPMP firmware destination)
|-
| 0x1F01C7000
| 0x8000F000
| 0x1000
| 0x40000000000324
| DRAM (SE Context Save destination)
|-
| 0x1F01E0000
| 0x7C010000
| 0x2000
| 0x300
| TZRAM (RWX pk2ldr for init)
|-
| 0x1F01F4000
| X
| 0x1000
| 0x40000000000723
| DRAM (SPL .bss buffer visible to the Security Engine)
|-
| 0x1F01F6000
| 0x7C010000
| 0x1000
| 0x40000000000300
| TZRAM (stacks)
|-
| 0x1F01F8000
| 0x7C011000
| 0x1000
| 0x40000000000300
| TZRAM (stacks)
|-
| 0x1F01FA000
| 0x7C01D000
| 0x1000
| 0x40000000000300
| TZRAM (stacks, warmboot crt0)
|-
| 0x1F01FC000
| 0x7C01E000
| 0x1000
| 0x40000000000300
| TZRAM (L2 Page Table)
|-
| 0x1F01FE000
| 0x7C01F000
| 0x1000
| 0x40000000000300
| TZRAM (L3 Page Table)
|-
|}

== [[6.0.0]] ==
6.0.0 reduced the .rwdata segment to one page (previously 2).

{| class="wikitable" border="1"
|-
! Vmem
! Physmem
! Size
! Descriptor ORR-value
! Description
|-
| 0x7C010000
| 0x7C010000
| 0x10000
| 0x300
| TZRAM Identity RWX (for init)
|-
| 0x40020000
| 0x40020000
| 0x20000
| 0x300
| IRAM Identity RWX (for init)
|-
| 0x1F0080000
| 0x50041000
| 0x1000
| 0x40000000000304
| ARM Interrupt Distributor
|-
| 0x1F0082000
| 0x50042000
| 0x2000
| 0x40000000000304
| Interrupt Controller Physical CPU
|-
| 0x1F0085000
| 0x70006000
| 0x1000
| 0x40000000000324
| UART-A
|-
| 0x1F0087000
| 0x60006000
| 0x1000
| 0x40000000000324
| Clock and Reset
|-
| 0x1F0089000
| 0x7000E000
| 0x1000
| 0x40000000000304
| PMC
|-
| 0x1F008B000
| 0x60005000
| 0x1000
| 0x40000000000304
| Timers
|-
| 0x1F008D000
| 0x6000C000
| 0x1000
| 0x40000000000304
| System Registers
|-
| 0x1F008F000
| 0x70012000
| 0x2000
| 0x40000000000304
| Security Engine
|-
| 0x1F00AD000
| 0x70412000
| 0x2000
| 0x40000000000304
| Undocumented/Not Present (Security Engine for Mariko?)
|-
| 0x1F0092000
| 0x700F0000
| 0x1000
| 0x40000000000304
| SYSCTR0
|-
| 0x1F0094000
| 0x70019000
| 0x1000
| 0x40000000000304
| Memory Controller
|-
| 0x1F0096000
| 0x7000F000
| 0x1000
| 0x40000000000304
| Fuse Registers
|-
| 0x1F0098000
| 0x70000000
| 0x4000
| 0x40000000000304
| MISC Registers
|-
| 0x1F009D000
| 0x60007000
| 0x1000
| 0x40000000000304
| Flow Controller
|-
| 0x1F009F000
| 0x40002000
| 0x1000
| 0x40000000000304
| IRAM
|-
| 0x1F00A1000
| 0x7000D000
| 0x1000
| 0x40000000000304
| I2C-5
|-
| 0x1F00A3000
| 0x6000D000
| 0x1000
| 0x40000000000304
| GPIO-1
|-
| 0x1F00A5000
| 0x7000C000
| 0x1000
| 0x40000000000304
| I2C
|-
| 0x1F00A7000
| 0x6000F000
| 0x1000
| 0x40000000000304
| BPMP Exception Vectors
|-
| 0x1F00A9000
| 0x7001C000
| 0x1000
| 0x40000000000304
| MC0
|-
| 0x1F00AB000
| 0x7001D000
| 0x1000
| 0x40000000000304
| MC1
|-
| 0x1F0100000
| 0x7C010000
| 0x10000
| 0x40000000000380
| TZRAM (R-- for context save)
|-
| 0x1F0140000
| 0x7C012000
| 0x9000
| 0x300
| TZRAM (R-X .text)
|-
| 0x1F0149000
| 0x7C01B000
| 0x1000
| 0x40000000000300
| TZRAM (RW- .rodata)
|-
| 0x1F014A000
| 0x7C01C000
| 0x1000
| 0x40000000000300
| TZRAM (RW- .rwdata)
|-
| 0x1F01A0000
| 0x40020000
| 0x10000
| 0x40000000000324
| IRAM (RW- for context save)
|-
| 0x1F01B0000
| 0x40003000
| 0x1000
| 0x40000000000324
| IRAM (BPMP firmware destination)
|-
| 0x1F01C7000
| 0x8000F000
| 0x1000
| 0x40000000000324
| DRAM (SE Context Save destination)
|-
| 0x1F01E0000
| 0x7C010000
| 0x2000
| 0x300
| TZRAM (RWX pk2ldr for init)
|-
| 0x1F01F4000
| X
| 0x1000
| 0x40000000000723
| DRAM (SPL .bss buffer visible to the Security Engine)
|-
| 0x1F01F6000
| 0x7C010000
| 0x1000
| 0x40000000000300
| TZRAM (stacks)
|-
| 0x1F01F8000
| 0x7C011000
| 0x1000
| 0x40000000000300
| TZRAM (stacks)
|-
| 0x1F01FA000
| 0x7C01D000
| 0x1000
| 0x40000000000300
| TZRAM (stacks, warmboot crt0)
|-
| 0x1F01FC000
| 0x7C01E000
| 0x1000
| 0x40000000000300
| TZRAM (L2 Page Table)
|-
| 0x1F01FE000
| 0x7C01F000
| 0x1000
| 0x40000000000300
| TZRAM (L3 Page Table)
|-
|}

= IRAM =
== [[BIT|BIT]] ==
When copied to IRAM at address 0x40000000, the BCT has an additional header called Boot Info Table as follows.

{| class="wikitable" border="1"
|-
! Offset
! Size
! Field
! Description
|-
| 0x00
| 0x04
| unk_version0
|
0x00210001
|-
| 0x04
| 0x04
| unk_version1
|
0x00210001
|-
| 0x08
| 0x04
| unk_version2
|
0x00210001
|-
| 0x0C
| 0x04
| boot_type
|
BOOT_TYPE_COLD = 1
BOOT_TYPE_RECOVERY = 2
BOOT_TYPE_UART = 3
BOOT_TYPE_EXIT_RCM = 4
|-
0x4C: bct_data_addr (address of the actual BCT)
|-
| 0x50
| 0x18*4
| bootloader_headers[4]
|
{| class="wikitable" border="1"
|-
! Offset
! Size
! Field
|-
| 0x00
| 0x04
| is_active
|-
| 0x04
| 0x04
| start_block
|-
| 0x08
| 0x04
| start_page
|-
| 0x0C
| 0x04
| length
|-
| 0x10
| 0x04
| signed_start
|-
| 0x14
| 0x04
| signature
|-
|}
|-
| 0xB0
| 0x40
|
|
|-
| 0xF0
| 0x04
|
|
bct_end_addr
|-
| 0xF4
| 0x0C
|
|
|-
|}

bct_data_addr should pint to a bct that contains the keyblob.

It's used in key generation in PK1.

PK11 checks boot_type to be cold, if it's not it panics.

bootloader_headers[0] or bootloader_headers[1] should be set to active. It is also checked by PK11.

= Notes =
== 2.0.0 ==
Granule size for TTBR0*_EL1 is 4KB.
TTBR0_EL1 vmem starts at vaddr 0x0.
vmem end-addr for TTBR1_EL1 is 0xffffffffffffffff. vmem start-addr for TTBR1_EL1 is 0xFFFFFFF000000000.
T0SZ = 31. Hence, bit-size of the TTBR0*_EL1 vmem region is 33. (0x0000000200000000)
T1SZ = 28. Hence, bit-size of the TTBR1*_EL1 vmem region is 36. (0x0000001000000000)

Note: ARM config for TTBR0 is presumably configured for userland later.

See arm-doc for "Table D4-25 Translation table entry addresses when using the 4KB translation granule".

See arm-doc for "Overview of VMSAv8-64 address translation using the 4KB translation granule".

See arm-doc for "Table D4-11 TCR.TnSZ values and IA ranges, 4K granule with no concatenation of tables".
Both TTBR*_EL1 use "Initial lookup level" 1. Therefore, the TTBR*_EL1 tables are level1.

Due to T*SZ, Stage1/Stage2 translation for the initial table(level1) are the same, except Stage2 uses hard-coded T0SZ.
Basically, the table is accessed as: ((u64*)tablebase)[<IA[y:30]>], where y = (37-T*SZ)+26. That is, starting at bit "y" ending(inclusive) at bit30. For TTBR0*_EL1, y = 32, while for TTBR1_EL1 y = 35.
Hence, for TTBR0, index=((vaddr>>30) & 0x7), and for TTBR1, index=((vaddr>>30) & 0x3f).

"Vector Base Address Register (EL1)" = 0xfffffff7ffc50800.

The table for TTBR0 only contains the following:
* Vmem 0x80000000 is mapped to physmem 0x80000000, using a size loaded from a register. This is only done when: "endaddr = 0x7fffffff + size; if(endaddr >= 0x80000001){...}"
** The size is loaded from: "(u32 *0x70019050 & 0x3fff) << 20;"
** The value written to the MMU-table descriptor is: "physaddr | val | 0x709;". val is 1<<52 when "tmp>>34" is non-zero and when "if((physaddr & 0x3c0000000) == 0)", otherwise val=0. tmp=size at the start and increased by 0xffffffffc0000000 each loop iteration. physaddr is increased by 0x40000000 each loop iteration.

TTBR1:
* vmem 0xFFFFFFF800000000 is mapped to physmem 0x80000000. Similar to above, except tmp=0 due to wrap-around, etc. This also has usermode/kernel XN enabled in the descriptor ORR-value. The chunksize used when increasing addr is 0xfffffff840000000, with another +=0x40000000 separate from the addr cmp for the loop.
** "endaddr = 0x3fffffff + (<size from above> | 0xfffffff800000000); enaddr = (endaddr & 0xffffffffc0000000)-1; if(endaddr >= 0xfffffff800000001){<map mem>}"

* Initializes level2 pagetable descriptor for vmem 0xFFFFFFF7C0000000. descriptor = 0x3 | physaddr. physaddr is core-specific.
* Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FFC00000. descriptor = 0x3 | physaddr. physaddr is core-specific.
* The content of the pagetable for the following level3 mmutables are not initialized in the main mmutable-init func. descriptor = 0x8007c003(0x3 | <physaddr tablebase>). tablebase=0x8007c000.
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FEE00000. physaddr = tablebase + (0x1<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF000000. physaddr = tablebase + (0x2<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF200000. physaddr = tablebase + (0x3<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FFA00000. physaddr = tablebase + (0x7<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FEC00000. physaddr = tablebase.
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF400000. physaddr = tablebase + (0x4<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF600000. physaddr = tablebase + (0x5<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF800000. physaddr = tablebase + (0x6<<12).

Memory layout

2018-09-03T18:30:37Z

Balika011: /* BCT */

= Userspace =
The userspace virtual address space can be either 32 or 36 bits. [2.0.0+] introduced support for 38 bit address spaces.

There are two regions randomized and enforced by the kernel, each one with upper bits random and 2MB-aligned:
* ReservedHeapRegion, available from [[SVC#svcGetInfo]].
* ReservedMapRegion, available from [[SVC#svcGetInfo]].
* [2.0.0+] NewReservedMapRegion, available from [[SVC#svcGetInfo]].
* [2.0.0+] TlsIoRegion, not available to userspace.

The main binary is placed at an address that is provided to the kernel by Loader via [[SVC#svcCreateProcess]].

Typically on 2.0.0+ systems, the main binary region has randomness in bits 37-21.

For the stack mapping region, the userland randomizes a page-offset where to start inside the region. This adds some additional entropy.

Binaries mapped by RO are mapped randomly everywhere in the entire address space. The base address for each NRO has all bits randomized and are 4K-aligned. This means that typically, on 2.0.0+ systems, bits 37-12 of the NRO base address are random.

For all binaries(main area / NROs), the R-- section is always located immediately after R-X. The RW- section is always located immediately after the R-- section. Hence, there's no extra randomization / guard-pages for these sections.

On version [[1.0.0]], the initial binaries loaded into memory by the kernel always have the upper 32-bits as all-zero, so there are 6 fewer bits of layout randomization.

Binaries loaded within the main-binary-region are loaded into memory in the following order, immediately after each other, for the binaries which exist in [[ExeFS]]:
* rtld
* main
* subsdk*
* sdk

== ASLR Implementation ==
The kernel uses a MT19937 random number generator, seeded by a [[SMC#GetRandomBytes|smcGetRandomBytes]]
=== 1.0.0 ===

if (AddressSpaceType == 2) {
BaseAddr = 0x80000000; // 64-bit
RandomMax = 0x6400;
}
else {
BaseAddr = 0x40000000; // 32-bit
RandomMax = 0x200;
}

if (AddressSpaceType == 4) {
MapRegionSize = 0;
HeapRegionSize = 0x80000000;
}
else {
MapRegionSize = 0x40000000;
HeapRegionSize = 0x40000000;
}

if (EnableAslr) {
rnd0 = GetRandomRange(0, RandomMax) << 21;
rnd1 = GetRandomRange(0, RandomMax) << 21;
}
else {
rnd0 = rnd1 = 0;
}

this->MapBaseAddr = BaseAddr + min(rnd0, rnd1)
this->HeapRegionBaseAddr = this->MapBaseAddr + MapRegionSize + max(rnd0, rnd1) - min(rnd0, rnd1)

= Kernel =
For more details, see [[#Notes]]. Here comes a summary.

PXN bit is set in the MMU descriptor for userland code pages. This means that userland code pages are not executable in kernel mode (this is equivalent to SMEP on x86).

For userland pages, the kernel has same access as userland (either both are read-only or both are read-write). It does not have SMAP. The previous rule has one exception: pages that are mapped unreadable in usermode are still forced readable from kernelmode.

KASLR is being used since [[5.0.0]], but not before, with the following pseudocode (might contains some errors):

<code><pre>
DRAM crt0 mapping (ttbr1): offsets DRAM with (rand64ViaSmc() % 0x3FFF0 << 21), allocates exactly (end - _start) + 1GB.
This is a "linear" mapping. Permissions are set properly.

KERN_ADDRSPACE := [VA(_start) : min(0xFFFFFFFFFFE00000 - VA(_start), 0x40000000)]
DRAM_FROM_SECTION1 := DRAM[0x808cd000:] // 0x808cd000 corresponds to start of section1 (loaded INI1) data, reused later

/* Global Randomize range: 0xFFFFFF8000000000 to 0xFFFFFFFFFFE00000. */
/*
Randomize picks a random integer in ranges, clears as many low bits required,
then checks if the address is acceptable, if not it attempts to iterate through page table entries.

If it doesn't find anything, it picks another integer. In case of general failure, the whole operation
may be done from the start again (maybe ?).
*/

/* Core0 executes this big KASLR function, then powers on the other CPUs (?). */
MapPartially(RandomizeL1Boundary(DRAM, sizeof(DRAM)) -> DRAM_FROM_SECTION1: offsetof DRAM_FROM_SECTION1,

/* Randomize */
KERN_ADDRSPACE {
Randomize(IOAndInitialStacks, 0x2000000) {
Map(Randomize(UartA, 0x1000)) -> UartA,
GuardPage,
Map(Randomize(Gicd, 0x1000)) -> Gicd,
GuardPage,
Map(Randomize(Gicc, 0x1000)) -> Gicc,
ForEachCore {
GuardPage,
Map(Randomize(EntryThreadStack, 0x1000)) -> NextFreePage(),
GuardPage,
Map(Randomize(IdleSchedulerThreadStack, 0x1000)) -> NextFreePage(),
GuardPage,
Map(Randomize(EL1AbortStack, 0x1000)) -> NextFreePage(),
}
},

Randomize(KernelStacks, 0xE00000),
Map(Randomize(SlabHeaps, 0x7E9000, AFTER(VA(_end)) -> PA(_end)),
Randomize(Kip1DecompressionBuffer, 0x8000000), /* 128 MB VA range */
},

Map(RandomizePageBoundary(GuardPage + KCoreContext * 4)) -> NextFreePages(4)
</pre></code>

== 1.0.0 ==
{| class="wikitable" border="1"
|-
! Virtual || Physical || Size || Attributes || Permissions || Description
|-
| 0xFFFFFFFFBFC00000-0xFFFFFFFFBFC45FFF || 0x800A0000 || 0x46000 || 0x78B || R-X || Kernel .text
|-
| 0xFFFFFFFFBFC46000-0xFFFFFFFFBFC48FFF || 0x800E6000 || 0x3000 || 0x6000000000078B || R-- || Kernel .rodata
|-
| 0xFFFFFFFFBFC49000-0xFFFFFFFFBFC4FFFF || 0x800E9000 || 0x7000 || 0x6000000000070B || RW- || Kernel .data+.bss
|-
| 0xFFFFFFFFBFD72000-0xFFFFFFFFBFD72FFF || 0x6000F000 || 0x1000 || 0x60000000000607 || RW- || Exception vectors
|-
| 0xFFFFFFFFBFDB5000-0xFFFFFFFFBFDB5FFF || 0x60007000 || 0x1000 || 0x60000000000607 || RW- || Flow controller
|-
| 0xFFFFFFFFBFDB7000-0xFFFFFFFFBFDB7FFF || 0x60004000 || 0x1000 || 0x60000000000607 || RW- || Primary ICTLR
|-
| 0xFFFFFFFFBFDB9000-0xFFFFFFFFBFDB9FFF || 0x60001000 || 0x1000 || 0x60000000000607 || RW- || Resource Semaphore
|-
| 0xFFFFFFFFBFDBB000-0xFFFFFFFFBFDBBFFF || 0x70016000 || 0x2000 || 0x60000000000607 || RW- || ATOMICS
|-
| 0xFFFFFFFFBFDBE000-0xFFFFFFFFBFDBEFFF || 0x7000E000 || 0x1000 || 0x60000000000607 || RW- || PMC
|-
| 0xFFFFFFFFBFDC0000-0xFFFFFFFFBFDC0FFF || 0x60006000 || 0x1000 || 0x60000000000607 || RW- || Clock and reset
|-
| 0xFFFFFFFFBFDC2000-0xFFFFFFFFBFDC2FFF || 0x7001D000 || 0x1000 || 0x60000000000607 || RW- || MC1
|-
| 0xFFFFFFFFBFDC4000-0xFFFFFFFFBFDC4FFF || 0x7001C000 || 0x1000 || 0x60000000000607 || RW- || MC0
|-
| 0xFFFFFFFFBFDC6000-0xFFFFFFFFBFDC6FFF || 0x70019000 || 0x1000 || 0x60000000000607 || RW- || MC
|-
| 0xFFFFFFFFBFDC8000-0xFFFFFFFFBFDC8FFF || 0x70006000 || 0x1000 || 0x60000000000607 || RW- || UART-A
|-
| 0xFFFFFFFFBFDCA000-0xFFFFFFFFBFDCBFFF || 0x80060000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| 0xFFFFFFFFBFDCE000-0xFFFFFFFFBFDCFFFF || 0x80068000 || 0x2000 || 0x6000000000070B || RW- || Kernel main stack (cpu0)
|-
| 0xFFFFFFFFBFDD2000-0xFFFFFFFFBFDD2FFF || 0x80070000 || 0x1000 || 0x6000000000070B || RW- || Kernel runner stack (cpu0)
|-
| 0xFFFFFFFFBFDD4000-0xFFFFFFFFBFDD5FFF || 0x80062000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| 0xFFFFFFFFBFDD8000-0xFFFFFFFFBFDD9FFF || 0x8006A000 || 0x2000 || 0x6000000000070B || RW- || Kernel main stack (cpu1)
|-
| 0xFFFFFFFFBFDDC000-0xFFFFFFFFBFDDCFFF || 0x80071000 || 0x1000 || 0x6000000000070B || RW- || Kernel runner stack (cpu1)
|-
| 0xFFFFFFFFBFDDE000-0xFFFFFFFFBFDDFFFF || 0x80064000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| 0xFFFFFFFFBFDE2000-0xFFFFFFFFBFDE3FFF || 0x8006C000 || 0x2000 || 0x6000000000070B || RW- || Kernel main stack (cpu2)
|-
| 0xFFFFFFFFBFDE6000-0xFFFFFFFFBFDE6FFF || 0x80072000 || 0x1000 || 0x6000000000070B || RW- || Kernel runner stack (cpu2)
|-
| 0xFFFFFFFFBFDE8000-0xFFFFFFFFBFDE9FFF || 0x80066000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| 0xFFFFFFFFBFDEC000-0xFFFFFFFFBFDEDFFF || 0x8006E000 || 0x2000 || 0x6000000000070B || RW- || Kernel main stack (cpu3)
|-
| 0xFFFFFFFFBFDF0000-0xFFFFFFFFBFDF0FFF || 0x80073000 || 0x1000 || 0x6000000000070B || RW- || Kernel runner stack (cpu3)
|-
| 0xFFFFFFFFBFDFB000-0xFFFFFFFFBFDFBFFF || 0x50041000 || 0x1000 || 0x60000000000607 || RW- || ARM Interrupt Distributor
|-
| 0xFFFFFFFFBFDFD000-0xFFFFFFFFBFDFDFFF || 0x50042000 || 0x1000 || 0x60000000000607 || RW- || Interrupt Controller Physical CPU interface
|-
| 0xFFFFFFFFBFDF2000-0xFFFFFFFFBFDF3FFF || 0x80060000+(cpuid*0x2000) || 0x2000 || 0x6000000000070B || RW- ||
|-
| 0xFFFFFFFFBFDF6000-0xFFFFFFFFBFDF7FFF || 0x80068000+(cpuid*0x2000) || 0x2000 || 0x6000000000070B || RW- || Kernel main stack (per-core self-mirror)
|-
| 0xFFFFFFFFBFDFF000-0xFFFFFFFFBFDFFFFF || 0x80084000+(cpuid*0x1000) || 0x1000 || 0x6000000000070B || RW- || Kernel runner stack (per-core self-mirror)
|-
| 0xFFFFFFFE00000000-... || 0x80000000 || ... || 0x60000000000709 || RW- || Raw DRAM access
|}

== 2.0.0 ==
{| class="wikitable" border="1"
|-
! Cores || Virtual || Physical || Size || Attributes || Permissions || Description
|-
| All || 0xFFFFFFF7FFC00000-0xFFFFFFF7FFC62FFF || 0x800A0000 || 0x63000 || 0x78B || R-X || Kernel .text
|-
| All || 0xFFFFFFF7FFC63000-0xFFFFFFF7FFC65FFF || 0x80103000 || 0x3000 || 0x6000000000078B || R-- || Kernel .rodata
|-
| All || 0xFFFFFFF7FFC66000-0xFFFFFFF7FFC6EFFF || 0x80106000 || 0x9000 || 0x6000000000070B || RW- || Kernel .data+.bss
|-
| All || 0xFFFFFFF7FFDC0000-0xFFFFFFF7FFDC0FFF || 0x60006000 || 0x1000 || 0x60000000000607 || RW- || Clock and Reset
|-
| All || 0xFFFFFFF7FFDC2000-0xFFFFFFF7FFDC2FFF || 0x7001D000 || 0x1000 || 0x60000000000607 || RW- || MC1
|-
| All || 0xFFFFFFF7FFDC4000-0xFFFFFFF7FFDC4FFF || 0x7001C000 || 0x1000 || 0x60000000000607 || RW- || MC0
|-
| All || 0xFFFFFFF7FFDC6000-0xFFFFFFF7FFDC6FFF || 0x70019000 || 0x1000 || 0x60000000000607 || RW- || MC
|-
| All || 0xFFFFFFF7FFDC8000-0xFFFFFFF7FFDC8FFF || 0x70006000 || 0x1000 || 0x60000000000607 || RW- || UART-A
|-
| All || 0xFFFFFFF7FFDCA000-0xFFFFFFF7FFDCAFFF || 0x80060000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDCE000-0xFFFFFFF7FFDCEFFF || 0x80068000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDD2000-0xFFFFFFF7FFDD2FFF || 0x80070000 || 0x1000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDD4000-0xFFFFFFF7FFDD4FFF || 0x80062000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDD8000-0xFFFFFFF7FFDD8FFF || 0x8006A000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDDC000-0xFFFFFFF7FFDDCFFF || 0x80071000 || 0x1000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDDE000-0xFFFFFFF7FFDDEFFF || 0x80064000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDE2000-0xFFFFFFF7FFDE2FFF || 0x8006C000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDE6000-0xFFFFFFF7FFDE6FFF || 0x80072000 || 0x1000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDE8000-0xFFFFFFF7FFDE8FFF || 0x80066000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDEC000-0xFFFFFFF7FFDECFFF || 0x8006E000 || 0x2000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDF0000-0xFFFFFFF7FFDF0FFF || 0x80073000 || 0x1000 || 0x6000000000070B || RW- ||
|-
| All || 0xFFFFFFF7FFDFB000-0xFFFFFFF7FFDFBFFF || 0x50041000 || 0x1000 || 0x60000000000607 || RW- || ARM Interrupt Distributor
|-
| All || 0xFFFFFFF7FFDFD000-0xFFFFFFF7FFDFDFFF || 0x50042000 || 0x1000 || 0x60000000000607 || RW- || Interrupt Controller Physical CPU interface
|-
| All || 0xFFFFFFF800000000-... || 0x80000000 || ... || 0x60000000000709 || RW- || Raw DRAM access
|}

== 3.0.0 ==
{| class="wikitable" border="1"
|-
! Cores || Virtual || Physical || Size || Attributes || Permissions || Description
|-
| All || 0xFFFFFFF7FFC00000-0xFFFFFFF7FFC4AFFF || 0x800A0000 || 0x4B000 || 0x78B || R-X || Kernel .text
|-
| All || 0xFFFFFFF7FFC4B000-0xFFFFFFF7FFC4DFFF || 0x800EB000 || 0x3000 || 0x6000000000078B || R-- || Kernel .rodata
|-
| All || 0xFFFFFFF7FFC4E000-0xFFFFFFF7FFC5AFFF || 0x800EE000 || 0xD000 || 0x6000000000070B || RW- || Kernel .data+.bss
|-
| All || 0xFFFFFFF7FFDAC000-0xFFFFFFF7FFDACFFF || 0x60006000 || 0x1000 || 0x60000000000607 || RW- || Clock and Reset
|-
| All || 0xFFFFFFF7FFDAE000-0xFFFFFFF7FFDAEFFF || 0x7001D000 || 0x1000 || 0x60000000000607 || RW- || MC1
|-
| All || 0xFFFFFFF7FFDB0000-0xFFFFFFF7FFDB0FFF || 0x7001C000 || 0x1000 || 0x60000000000607 || RW- || MC0
|-
| All || 0xFFFFFFF7FFDB2000-0xFFFFFFF7FFDB2FFF || 0x70019000 || 0x1000 || 0x60000000000607 || RW- || MC
|-
| All || 0xFFFFFFF7FFDB4000-0xFFFFFFF7FFDB4FFF || 0x70006000 || 0x1000 || 0x60000000000607 || RW- || UART-A
|-
| All || 0xFFFFFFF7FFDFB000-0xFFFFFFF7FFDFBFFF || 0x50041000 || 0x1000 || 0x60000000000607 || RW- || ARM Interrupt Distributor
|-
| All || 0xFFFFFFF7FFDFD000-0xFFFFFFF7FFDFDFFF || 0x50042000 || 0x1000 || 0x60000000000607 || RW- || Interrupt Controller Physical CPU interface
|}

== 4.0.0 ==
{| class="wikitable" border="1"
|-
! Cores || Virtual || Physical || Size || Attributes || Permissions || Description
|-
| All || 0xFFFFFFF7FFC00000-0xFFFFFFF7FFC50FFF || 0x800A0000 || 0x51000 || 0x4000000000078B || R-X || Kernel .text
|-
| All || 0xFFFFFFF7FFC51000-0xFFFFFFF7FFC53FFF || 0x800F1000 || 0x3000 || 0x6000000000078B || R-- || Kernel .rodata
|-
| All || 0xFFFFFFF7FFC54000-0xFFFFFFF7FFC61FFF || 0x800F4000 || 0xE000 || 0x6000000000070B || RW- || Kernel .data+.bss
|-
| All || 0xFFFFFFF7FFDAC000-0xFFFFFFF7FFDACFFF || 0x60006000 || 0x1000 || 0x60000000000607 || RW- || Clock and Reset
|-
| All || 0xFFFFFFF7FFDAE000-0xFFFFFFF7FFDAEFFF || 0x7001D000 || 0x1000 || 0x60000000000607 || RW- || MC1
|-
| All || 0xFFFFFFF7FFDB0000-0xFFFFFFF7FFDB0FFF || 0x7001C000 || 0x1000 || 0x60000000000607 || RW- || MC0
|-
| All || 0xFFFFFFF7FFDB2000-0xFFFFFFF7FFDB2FFF || 0x70019000 || 0x1000 || 0x60000000000607 || RW- || MC
|-
| All || 0xFFFFFFF7FFDB4000-0xFFFFFFF7FFDB4FFF || 0x70006000 || 0x1000 || 0x60000000000607 || RW- || UART-A
|-
| All || 0xFFFFFFF7FFDFB000-0xFFFFFFF7FFDFBFFF || 0x50041000 || 0x1000 || 0x60000000000607 || RW- || ARM Interrupt Distributor
|-
| All || 0xFFFFFFF7FFDFD000-0xFFFFFFF7FFDFDFFF || 0x50042000 || 0x1000 || 0x60000000000607 || RW- || Interrupt Controller Physical CPU interface
|}

The rest are are mapped to core-specific physaddrs, each one is 0x1000-bytes. Descriptor ORR-value = 0x6000000000070B.

{| class="wikitable" border="1"
|-
! Vmem
! Physmem
|-
| 0xFFFFFFF7FFDF7000
| <physaddr from vmem 0xFFFFFFF7FFDF6000> + 0x1000
|-
| 0xFFFFFFF7FFDF3000
| <physaddr from vmem 0xFFFFFFF7FFDF2000> + 0x1000
|-
| 0xFFFFFFF7FFDF6000
| 0x800XX000
|-
| 0xFFFFFFF7FFDF2000
| 0x800XX000
|-
| 0xFFFFFFF7FFDFF000
| 0x800XX000
|-
| 0xFFFFFFF7FFDF9000
| 0x800XX000
|}

= Secure Monitor =

Unless otherwise mentionned, block descriptors (in our case, the one uses for the DRAM identity mapping) are all ORRed by 0x401 and page descriptors by 0x403.

== [[1.0.0]] ==

{| class="wikitable" border="1"
|-
! Vmem
! Physmem
! Size
! Descriptor ORR-value
! Permissions
! Description
|-
| 0x1F0000000
| 0x50041000
| 0x1000
| 0x40000000000324
|
| ARM Interrupt Distributor
|-
| 0x1F0002000
| 0x50042000
| 0x1000
| 0x40000000000324
|
| Interrupt Controller Physical CPU Interface
|-
| 0x1F0005000
| 0x70006000
| 0x1000
| 0x40000000000324
|
| UART-A
|-
| 0x1F0007000
| 0x60006000
| 0x1000
| 0x40000000000324
|
| Clock and Reset
|-
| 0x1F0009000
| 0x7000E000
| 0x1000
| 0x40000000000304
|
| PMC
|-
| 0x1F000B000
| 0x60005000
| 0x1000
| 0x40000000000304
|
| TMR
|-
| 0x1F000D000
| 0x6000C000
| 0x1000
| 0x40000000000304
|
| System Registers
|-
| 0x1F000F000
| 0x70012000
| 0x2000
| 0x40000000000304
|
| SE
|-
| 0x1F0012000
| 0x700F0000
| 0x1000
| 0x40000000000304
|
| SYSCTR0
|-
| 0x1F0014000
| 0x70019000
| 0x1000
| 0x40000000000304
|
| MC
|-
| 0x1F0016000
| 0x7000F000
| 0x1000
| 0x40000000000304
|
| FUSE
|-
| 0x1F0018000
| 0x70000000
| 0x4000
| 0x40000000000304
|
| MISC
|-
| 0x1F001D000
| 0x60007000
| 0x1000
| 0x40000000000304
|
| Flow controller
|-
| 0x1F001F000
| 0x40002000
| 0x1000
| 0x40000000000304
|
| IRAM
|-
| 0x1F0021000
| 0x7000D000
| 0x1000
| 0x40000000000304
|
| I2C-5
|-
| 0x1F0023000
| 0x6000D000
| 0x1000
| 0x40000000000304
|
| GPIO-1
|-
| 0x1F0025000
| 0x7000C000
| 0x1000
| 0x40000000000304
|
| I2C
|-
| 0x1F0180000
| 0x40020000
| 0x10000
| 0x40000000000324
|
| IRAM
|-
| 0x1F01A0000
| 0x7C010000
| 0x10000
| 0x40000000000384
|
| TZRAM
|-
| 0x1F01C3000
| 0x80010000
| 0x10000
| 0x40000000000324
|
| EMEM
|-
| 0x1F01C2000
| 0x8000F000
| 0x1000
| 0x40000000000324
|
| EMEM
|-
| 0x1F01E0000
| 0x7C013000
| 0xB000
| 0x304
|
| TZRAM (Secure Monitor)
|-
| 0x1F01F0000
| 0x7C01E000
| 0x2000
| 0x304
|
| TZRAM (Secure Monitor and ARMv8 init)
|-
| 0x1F01F6000
| 0x7C01E000
| 0x1000
| 0x40000000000304
|
| TZRAM
|-
| 0x1F01F8000
| 0x7C01F000
| 0x1000
| 0x40000000000304
|
| TZRAM
|-
| 0x1F01FA000
| 0x7C010000
| 0x1000
| 0x304
|
| TZRAM (Secure Monitor exception vectors)
|-
| 0x1F01FC000
| 0x7C011000
| 0x1000
| 0x40000000000304
|
| TZRAM
|-
| 0x1F01FE000
| 0x7C012000
| 0x1000
| 0x40000000000304
|
| TZRAM
|}

== [[2.0.0]] ==

{| class="wikitable" border="1"
|-
! Vmem
! Physmem
! Size
! Descriptor ORR-value
! Permissions
! Description
|-
| 0x7C010000
| 0x7C010000
| 0x10000
| 0x300
|
| TZRAM
|-
| 0x40020000
| 0x40020000
| 0x20000
| 0x300
|
| iRAM-C
|-
| 0x1F0080000
| 0x50041000
| 0x1000
| 0x40000000000304
|
| ARM Interrupt Distributor
|-
| 0x1F0082000
| 0x50042000
| 0x2000
| 0x40000000000304
|
| Interrupt Controller Physical CPU interface
|-
| 0x1F0085000
| 0x70006000
| 0x1000
| 0x40000000000324
|
| UART-A
|-
| 0x1F0087000
| 0x60006000
| 0x1000
| 0x40000000000324
|
| Clock and Reset
|-
| 0x1F0089000
| 0x7000E000
| 0x1000
| 0x40000000000304
|
| PMC
|-
| 0x1F008B000
| 0x60005000
| 0x1000
| 0x40000000000304
|
| TMR
|-
| 0x1F008D000
| 0x6000C000
| 0x1000
| 0x40000000000304
|
| System Registers
|-
| 0x1F008F000
| 0x70012000
| 0x2000
| 0x40000000000304
|
| SE
|-
| 0x1F0092000
| 0x700F0000
| 0x1000
| 0x40000000000304
|
| SYSCTR0
|-
| 0x1F0094000
| 0x70019000
| 0x1000
| 0x40000000000304
|
| MC
|-
| 0x1F0096000
| 0x7000F000
| 0x1000
| 0x40000000000304
|
| FUSE (0x7000F800)
|-
| 0x1F0098000
| 0x70000000
| 0x4000
| 0x40000000000304
|
| MISC
|-
| 0x1F009D000
| 0x60007000
| 0x1000
| 0x40000000000304
|
| Flow Controller
|-
| 0x1F009F000
| 0x40002000
| 0x1000
| 0x40000000000304
|
| iRAM-A
|-
| 0x1F00A1000
| 0x7000D000
| 0x1000
| 0x40000000000304
|
| I2C5 - SPI 2B-6
|-
| 0x1F00A3000
| 0x6000D000
| 0x1000
| 0x40000000000304
|
| GPIO-1 - GPIO-8
|-
| 0x1F00A5000
| 0x7000C000
| 0x1000
| 0x40000000000304
|
| I2C-I2C4
|-
| 0x1F00A7000
| 0x6000F000
| 0x1000
| 0x40000000000304
|
| Exception vectors
|-
| 0x1F0180000
| 0x40020000
| 0x10000
| 0x40000000000324
|
| iRAM-C
|-
| 0x1F0190000
| 0x40003000
| 0x1000
| 0x40000000000324
|
| iRAM-A
|-
| 0x1F01A0000
| 0x7C010000
| 0x10000
| 0x40000000000380
|
| TZRAM
|-
| 0x1F01C3000
| 0x80010000
| 0x10000
| 0x40000000000324
|
| EMEM
|-
| 0x1F01C2000
| 0x8000F000
| 0x1000
| 0x40000000000324
|
| EMEM
|-
| 0x1F01E0000
| 0x7C013000
| 0xB000
| 0x300
|
| TZRAM (Secure Monitor)
|-
| 0x1F01F0000
| 0x7C01E000
| 0x2000
| 0x300
|
| TZRAM (Secure Monitor and ARMv8 init)
|-
| 0x1F01F4000
| <varies>
| 0x1000
| 0x40000000000320
|
| DRAM (SPL .bss buffer visible to the Security Engine)
|-
| 0x1F01F6000
| 0x7C01E000
| 0x1000
| 0x40000000000300
|
| TZRAM
|-
| 0x1F01F8000
| 0x7C01F000
| 0x1000
| 0x40000000000300
|
| TZRAM
|-
| 0x1F01FA000
| 0x7C010000
| 0x1000
| 0x300
|
| TZRAM (Secure Monitor exception vectors)
|-
| 0x1F01FC000
| 0x7C011000
| 0x1000
| 0x40000000000300
|
| TZRAM
|-
| 0x1F01FE000
| 0x7C012000
| 0x1000
| 0x40000000000300
|
| TZRAM
|}

== [[5.0.0]] ==
5.0.0 modified the address map to have separate .text, .rodata, and .rwdata segments, instead of a single RWX segment.

However, the .rodata and .rwdata segments are both (mistakenly?) mapped R-W.

Because the same L3 page is shared for all mappings, this required modifying segment layout significantly to prevent clashes.

{| class="wikitable" border="1"
|-
! Vmem
! Physmem
! Size
! Descriptor ORR-value
! Description
|-
| 0x7C010000
| 0x7C010000
| 0x10000
| 0x300
| TZRAM Identity RWX (for init)
|-
| 0x40020000
| 0x40020000
| 0x20000
| 0x300
| IRAM Identity RWX (for init)
|-
| 0x1F0080000
| 0x50041000
| 0x1000
| 0x40000000000304
| ARM Interrupt Distributor
|-
| 0x1F0082000
| 0x50042000
| 0x2000
| 0x40000000000304
| Interrupt Controller Physical CPU
|-
| 0x1F0085000
| 0x70006000
| 0x1000
| 0x40000000000324
| UART-A
|-
| 0x1F0087000
| 0x60006000
| 0x1000
| 0x40000000000324
| Clock and Reset
|-
| 0x1F0089000
| 0x7000E000
| 0x1000
| 0x40000000000304
| PMC
|-
| 0x1F008B000
| 0x60005000
| 0x1000
| 0x40000000000304
| Timers
|-
| 0x1F008D000
| 0x6000C000
| 0x1000
| 0x40000000000304
| System Registers
|-
| 0x1F008F000
| 0x70012000
| 0x2000
| 0x40000000000304
| Security Engine
|-
| 0x1F00AD000
| 0x70412000
| 0x2000
| 0x40000000000304
| Undocumented/Not Present (Security Engine for Mariko?)
|-
| 0x1F0092000
| 0x700F0000
| 0x1000
| 0x40000000000304
| SYSCTR0
|-
| 0x1F0094000
| 0x70019000
| 0x1000
| 0x40000000000304
| Memory Controller
|-
| 0x1F0096000
| 0x7000F000
| 0x1000
| 0x40000000000304
| Fuse Registers
|-
| 0x1F0098000
| 0x70000000
| 0x4000
| 0x40000000000304
| MISC Registers
|-
| 0x1F009D000
| 0x60007000
| 0x1000
| 0x40000000000304
| Flow Controller
|-
| 0x1F009F000
| 0x40002000
| 0x1000
| 0x40000000000304
| IRAM
|-
| 0x1F00A1000
| 0x7000D000
| 0x1000
| 0x40000000000304
| I2C-5
|-
| 0x1F00A3000
| 0x6000D000
| 0x1000
| 0x40000000000304
| GPIO-1
|-
| 0x1F00A5000
| 0x7000C000
| 0x1000
| 0x40000000000304
| I2C
|-
| 0x1F00A7000
| 0x6000F000
| 0x1000
| 0x40000000000304
| BPMP Exception Vectors
|-
| 0x1F00A9000
| 0x7001C000
| 0x1000
| 0x40000000000304
| MC0
|-
| 0x1F00AB000
| 0x7001D000
| 0x1000
| 0x40000000000304
| MC1
|-
| 0x1F0100000
| 0x7C010000
| 0x10000
| 0x40000000000380
| TZRAM (R-- for context save)
|-
| 0x1F0140000
| 0x7C012000
| 0x9000
| 0x300
| TZRAM (R-X .text)
|-
| 0x1F0149000
| 0x7C01B000
| 0x1000
| 0x40000000000300
| TZRAM (RW- .rodata)
|-
| 0x1F014A000
| 0x7C01C000
| 0x2000
| 0x40000000000300
| TZRAM (RW- .rwdata)
|-
| 0x1F01A0000
| 0x40020000
| 0x10000
| 0x40000000000324
| IRAM (RW- for context save)
|-
| 0x1F01B0000
| 0x40003000
| 0x1000
| 0x40000000000324
| IRAM (BPMP firmware destination)
|-
| 0x1F01C7000
| 0x8000F000
| 0x1000
| 0x40000000000324
| DRAM (SE Context Save destination)
|-
| 0x1F01E0000
| 0x7C010000
| 0x2000
| 0x300
| TZRAM (RWX pk2ldr for init)
|-
| 0x1F01F4000
| X
| 0x1000
| 0x40000000000723
| DRAM (SPL .bss buffer visible to the Security Engine)
|-
| 0x1F01F6000
| 0x7C010000
| 0x1000
| 0x40000000000300
| TZRAM (stacks)
|-
| 0x1F01F8000
| 0x7C011000
| 0x1000
| 0x40000000000300
| TZRAM (stacks)
|-
| 0x1F01FA000
| 0x7C01D000
| 0x1000
| 0x40000000000300
| TZRAM (stacks, warmboot crt0)
|-
| 0x1F01FC000
| 0x7C01E000
| 0x1000
| 0x40000000000300
| TZRAM (L2 Page Table)
|-
| 0x1F01FE000
| 0x7C01F000
| 0x1000
| 0x40000000000300
| TZRAM (L3 Page Table)
|-
|}

== [[6.0.0]] ==
6.0.0 reduced the .rwdata segment to one page (previously 2).

{| class="wikitable" border="1"
|-
! Vmem
! Physmem
! Size
! Descriptor ORR-value
! Description
|-
| 0x7C010000
| 0x7C010000
| 0x10000
| 0x300
| TZRAM Identity RWX (for init)
|-
| 0x40020000
| 0x40020000
| 0x20000
| 0x300
| IRAM Identity RWX (for init)
|-
| 0x1F0080000
| 0x50041000
| 0x1000
| 0x40000000000304
| ARM Interrupt Distributor
|-
| 0x1F0082000
| 0x50042000
| 0x2000
| 0x40000000000304
| Interrupt Controller Physical CPU
|-
| 0x1F0085000
| 0x70006000
| 0x1000
| 0x40000000000324
| UART-A
|-
| 0x1F0087000
| 0x60006000
| 0x1000
| 0x40000000000324
| Clock and Reset
|-
| 0x1F0089000
| 0x7000E000
| 0x1000
| 0x40000000000304
| PMC
|-
| 0x1F008B000
| 0x60005000
| 0x1000
| 0x40000000000304
| Timers
|-
| 0x1F008D000
| 0x6000C000
| 0x1000
| 0x40000000000304
| System Registers
|-
| 0x1F008F000
| 0x70012000
| 0x2000
| 0x40000000000304
| Security Engine
|-
| 0x1F00AD000
| 0x70412000
| 0x2000
| 0x40000000000304
| Undocumented/Not Present (Security Engine for Mariko?)
|-
| 0x1F0092000
| 0x700F0000
| 0x1000
| 0x40000000000304
| SYSCTR0
|-
| 0x1F0094000
| 0x70019000
| 0x1000
| 0x40000000000304
| Memory Controller
|-
| 0x1F0096000
| 0x7000F000
| 0x1000
| 0x40000000000304
| Fuse Registers
|-
| 0x1F0098000
| 0x70000000
| 0x4000
| 0x40000000000304
| MISC Registers
|-
| 0x1F009D000
| 0x60007000
| 0x1000
| 0x40000000000304
| Flow Controller
|-
| 0x1F009F000
| 0x40002000
| 0x1000
| 0x40000000000304
| IRAM
|-
| 0x1F00A1000
| 0x7000D000
| 0x1000
| 0x40000000000304
| I2C-5
|-
| 0x1F00A3000
| 0x6000D000
| 0x1000
| 0x40000000000304
| GPIO-1
|-
| 0x1F00A5000
| 0x7000C000
| 0x1000
| 0x40000000000304
| I2C
|-
| 0x1F00A7000
| 0x6000F000
| 0x1000
| 0x40000000000304
| BPMP Exception Vectors
|-
| 0x1F00A9000
| 0x7001C000
| 0x1000
| 0x40000000000304
| MC0
|-
| 0x1F00AB000
| 0x7001D000
| 0x1000
| 0x40000000000304
| MC1
|-
| 0x1F0100000
| 0x7C010000
| 0x10000
| 0x40000000000380
| TZRAM (R-- for context save)
|-
| 0x1F0140000
| 0x7C012000
| 0x9000
| 0x300
| TZRAM (R-X .text)
|-
| 0x1F0149000
| 0x7C01B000
| 0x1000
| 0x40000000000300
| TZRAM (RW- .rodata)
|-
| 0x1F014A000
| 0x7C01C000
| 0x1000
| 0x40000000000300
| TZRAM (RW- .rwdata)
|-
| 0x1F01A0000
| 0x40020000
| 0x10000
| 0x40000000000324
| IRAM (RW- for context save)
|-
| 0x1F01B0000
| 0x40003000
| 0x1000
| 0x40000000000324
| IRAM (BPMP firmware destination)
|-
| 0x1F01C7000
| 0x8000F000
| 0x1000
| 0x40000000000324
| DRAM (SE Context Save destination)
|-
| 0x1F01E0000
| 0x7C010000
| 0x2000
| 0x300
| TZRAM (RWX pk2ldr for init)
|-
| 0x1F01F4000
| X
| 0x1000
| 0x40000000000723
| DRAM (SPL .bss buffer visible to the Security Engine)
|-
| 0x1F01F6000
| 0x7C010000
| 0x1000
| 0x40000000000300
| TZRAM (stacks)
|-
| 0x1F01F8000
| 0x7C011000
| 0x1000
| 0x40000000000300
| TZRAM (stacks)
|-
| 0x1F01FA000
| 0x7C01D000
| 0x1000
| 0x40000000000300
| TZRAM (stacks, warmboot crt0)
|-
| 0x1F01FC000
| 0x7C01E000
| 0x1000
| 0x40000000000300
| TZRAM (L2 Page Table)
|-
| 0x1F01FE000
| 0x7C01F000
| 0x1000
| 0x40000000000300
| TZRAM (L3 Page Table)
|-
|}

= IRAM =
== [[BCT|BCT]] ==
When copied to IRAM at address 0x40000000, the BCT has an additional header as follows.

{| class="wikitable" border="1"
|-
! Offset
! Size
! Field
! Description
|-
| 0x00
| 0x50
| bct_global_header
|
0x00: unk_version0 (0x00210001)
0x04: unk_version1 (0x00210001)
0x08: unk_version2 (0x00210001)
0x0C: boot_type (1 (COLD) PK11 panics if it's not)
0x4C: bct_data_addr (address of the actual BCT)
|-
| 0x50
| 0x18
| bootloader0_header
|
0x00: is_active (if set to 0x01, bootloader0 is used)
|-
| 0x68
| 0x18
| bootloader1_header
|
0x00: is_active (if set to 0x01, bootloader1 is used)
|-
| 0x80
| 0x18
| bootloader2_header
|
0x00: is_active (if set to 0x01, bootloader2 is used)
|-
| 0x98
| 0x18
| bootloader3_header
|
0x00: is_active (if set to 0x01, bootloader3 is used)
|-
| 0xB0
| 0x50
|
|
0x40: bct_end_addr
|-
|}

= Notes =
== 2.0.0 ==
Granule size for TTBR0*_EL1 is 4KB.
TTBR0_EL1 vmem starts at vaddr 0x0.
vmem end-addr for TTBR1_EL1 is 0xffffffffffffffff. vmem start-addr for TTBR1_EL1 is 0xFFFFFFF000000000.
T0SZ = 31. Hence, bit-size of the TTBR0*_EL1 vmem region is 33. (0x0000000200000000)
T1SZ = 28. Hence, bit-size of the TTBR1*_EL1 vmem region is 36. (0x0000001000000000)

Note: ARM config for TTBR0 is presumably configured for userland later.

See arm-doc for "Table D4-25 Translation table entry addresses when using the 4KB translation granule".

See arm-doc for "Overview of VMSAv8-64 address translation using the 4KB translation granule".

See arm-doc for "Table D4-11 TCR.TnSZ values and IA ranges, 4K granule with no concatenation of tables".
Both TTBR*_EL1 use "Initial lookup level" 1. Therefore, the TTBR*_EL1 tables are level1.

Due to T*SZ, Stage1/Stage2 translation for the initial table(level1) are the same, except Stage2 uses hard-coded T0SZ.
Basically, the table is accessed as: ((u64*)tablebase)[<IA[y:30]>], where y = (37-T*SZ)+26. That is, starting at bit "y" ending(inclusive) at bit30. For TTBR0*_EL1, y = 32, while for TTBR1_EL1 y = 35.
Hence, for TTBR0, index=((vaddr>>30) & 0x7), and for TTBR1, index=((vaddr>>30) & 0x3f).

"Vector Base Address Register (EL1)" = 0xfffffff7ffc50800.

The table for TTBR0 only contains the following:
* Vmem 0x80000000 is mapped to physmem 0x80000000, using a size loaded from a register. This is only done when: "endaddr = 0x7fffffff + size; if(endaddr >= 0x80000001){...}"
** The size is loaded from: "(u32 *0x70019050 & 0x3fff) << 20;"
** The value written to the MMU-table descriptor is: "physaddr | val | 0x709;". val is 1<<52 when "tmp>>34" is non-zero and when "if((physaddr & 0x3c0000000) == 0)", otherwise val=0. tmp=size at the start and increased by 0xffffffffc0000000 each loop iteration. physaddr is increased by 0x40000000 each loop iteration.

TTBR1:
* vmem 0xFFFFFFF800000000 is mapped to physmem 0x80000000. Similar to above, except tmp=0 due to wrap-around, etc. This also has usermode/kernel XN enabled in the descriptor ORR-value. The chunksize used when increasing addr is 0xfffffff840000000, with another +=0x40000000 separate from the addr cmp for the loop.
** "endaddr = 0x3fffffff + (<size from above> | 0xfffffff800000000); enaddr = (endaddr & 0xffffffffc0000000)-1; if(endaddr >= 0xfffffff800000001){<map mem>}"

* Initializes level2 pagetable descriptor for vmem 0xFFFFFFF7C0000000. descriptor = 0x3 | physaddr. physaddr is core-specific.
* Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FFC00000. descriptor = 0x3 | physaddr. physaddr is core-specific.
* The content of the pagetable for the following level3 mmutables are not initialized in the main mmutable-init func. descriptor = 0x8007c003(0x3 | <physaddr tablebase>). tablebase=0x8007c000.
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FEE00000. physaddr = tablebase + (0x1<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF000000. physaddr = tablebase + (0x2<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF200000. physaddr = tablebase + (0x3<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FFA00000. physaddr = tablebase + (0x7<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FEC00000. physaddr = tablebase.
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF400000. physaddr = tablebase + (0x4<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF600000. physaddr = tablebase + (0x5<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF800000. physaddr = tablebase + (0x6<<12).