A-Team_Digital_Solutions/android_kernel_motorola_sm6375
Watch
2
0
Fork
You've already forked android_kernel_motorola_sm6375
 0
mirror of https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git synced 2026-10-29 03:01:39 -04:00
Code Issues Projects Releases Packages Wiki Activity

xtensa: cleanup MMU setup and kernel layout macros

Browse source 
Make kernel load address explicit, independent of the selected MMU
configuration and configurable from Kconfig. Do not restrict it to the
first 512MB of the physical address space.

Cleanup kernel memory layout macros:

- rename VECBASE_RESET_VADDR to VECBASE_VADDR, XC_VADDR to VECTOR_VADDR;
- drop VIRTUAL_MEMORY_ADDRESS and LOAD_MEMORY_ADDRESS;
- introduce PHYS_OFFSET and use it in __va and __pa definitions;
- synchronize MMU/noMMU vectors, drop unused NMI vector;
- replace hardcoded vectors offset of 0x3000 with Kconfig symbol.

Signed-off-by: Max Filippov <[email protected]>
This commit is contained in:
Max Filippov 2016-04-13 05:20:02 +03:00
commit a9f2fc628e
12 changed files with 98 additions and 105 deletions
Download patch file Download diff file Expand all files Collapse all files

45
Documentation/xtensa/mmu.txt
View file

@ -3,15 +3,8 @@ MMUv3 initialization sequence.
The code in the initialize_mmu macro sets up MMUv3 memory mapping
identically to MMUv2 fixed memory mapping. Depending on
CONFIG_INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX symbol this code is
located in one of the following address ranges:
0xF0000000..0xFFFFFFFF (will keep same address in MMU v2 layout;
typically ROM)
0x00000000..0x07FFFFFF (system RAM; this code is actually linked
at 0xD0000000..0xD7FFFFFF [cached]
or 0xD8000000..0xDFFFFFFF [uncached];
in any case, initially runs elsewhere
than linked, so have to be careful)
located in addresses it was linked for (symbol undefined), or not
(symbol defined), so it needs to be position-independent.
The code has the following assumptions:
This code fragment is run only on an MMU v3.
@ -28,24 +21,26 @@ TLB setup proceeds along the following steps.
PA = physical address (two upper nibbles of it);
pc = physical range that contains this code;
After step 2, we jump to virtual address in 0x40000000..0x5fffffff
that corresponds to next instruction to execute in this code.
After step 4, we jump to intended (linked) address of this code.
After step 2, we jump to virtual address in the range 0x40000000..0x5fffffff
or 0x00000000..0x1fffffff, depending on whether the kernel was loaded below
0x40000000 or above. That address corresponds to next instruction to execute
in this code. After step 4, we jump to intended (linked) address of this code.
The scheme below assumes that the kernel is loaded below 0x40000000.
Step 0 Step1 Step 2 Step3 Step 4 Step5
============ ===== ============ ===== ============ =====
VA PA PA VA PA PA VA PA PA
------ -- -- ------ -- -- ------ -- --
E0..FF -> E0 -> E0 E0..FF -> E0 F0..FF -> F0 -> F0
C0..DF -> C0 -> C0 C0..DF -> C0 E0..EF -> F0 -> F0
A0..BF -> A0 -> A0 A0..BF -> A0 D8..DF -> 00 -> 00
80..9F -> 80 -> 80 80..9F -> 80 D0..D7 -> 00 -> 00
60..7F -> 60 -> 60 60..7F -> 60
40..5F -> 40 40..5F -> pc -> pc 40..5F -> pc
20..3F -> 20 -> 20 20..3F -> 20
00..1F -> 00 -> 00 00..1F -> 00
Step0 Step1 Step2 Step3 Step4 Step5
===== ===== ===== ===== ===== =====
VA PA PA PA PA VA PA PA
------ -- -- -- -- ------ -- --
E0..FF -> E0 -> E0 -> E0 F0..FF -> F0 -> F0
C0..DF -> C0 -> C0 -> C0 E0..EF -> F0 -> F0
A0..BF -> A0 -> A0 -> A0 D8..DF -> 00 -> 00
80..9F -> 80 -> 80 -> 80 D0..D7 -> 00 -> 00
60..7F -> 60 -> 60 -> 60
40..5F -> 40 -> pc -> pc 40..5F -> pc
20..3F -> 20 -> 20 -> 20
00..1F -> 00 -> 00 -> 00
The default location of IO peripherals is above 0xf0000000. This may change
The default location of IO peripherals is above 0xf0000000. This may be changed
using a "ranges" property in a device tree simple-bus node. See ePAPR 1.1, §6.5
for details on the syntax and semantic of simple-bus nodes. The following
limitations apply: