diff options
| author | Max Filippov <jcmvbkbc@gmail.com> | 2012-12-03 15:01:43 +0400 |
|---|---|---|
| committer | Chris Zankel <chris@zankel.net> | 2013-05-09 01:07:09 -0700 |
| commit | e85e335f8ff615f74e29e09cc2599f095600114b (patch) | |
| tree | 8f09bbab5ca6a37f027fef17bf1de523ab574f10 /arch/xtensa/Kconfig | |
| parent | d83ff0bb828854d9e7172ac5d8d007a7466934c9 (diff) | |
xtensa: add MMU v3 support
MMUv3 comes out of reset with identity vaddr -> paddr mapping in the TLB
way 6:
Way 6 (512 MB)
Vaddr Paddr ASID Attr RWX Cache
---------- ---------- ---- ---- --- -------
0x00000000 0x00000000 0x01 0x03 RWX Bypass
0x20000000 0x20000000 0x01 0x03 RWX Bypass
0x40000000 0x40000000 0x01 0x03 RWX Bypass
0x60000000 0x60000000 0x01 0x03 RWX Bypass
0x80000000 0x80000000 0x01 0x03 RWX Bypass
0xa0000000 0xa0000000 0x01 0x03 RWX Bypass
0xc0000000 0xc0000000 0x01 0x03 RWX Bypass
0xe0000000 0xe0000000 0x01 0x03 RWX Bypass
This patch adds remapping code at the reset vector or at the kernel
_start (depending on CONFIG_INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX) that
reconfigures MMUv3 as MMUv2:
Way 5 (128 MB)
Vaddr Paddr ASID Attr RWX Cache
---------- ---------- ---- ---- --- -------
0xd0000000 0x00000000 0x01 0x07 RWX WB
0xd8000000 0x00000000 0x01 0x03 RWX Bypass
Way 6 (256 MB)
Vaddr Paddr ASID Attr RWX Cache
---------- ---------- ---- ---- --- -------
0xe0000000 0xf0000000 0x01 0x07 RWX WB
0xf0000000 0xf0000000 0x01 0x03 RWX Bypass
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Chris Zankel <chris@zankel.net>
Diffstat (limited to 'arch/xtensa/Kconfig')
| -rw-r--r-- | arch/xtensa/Kconfig | 29 |
1 files changed, 29 insertions, 0 deletions
diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig index b09de49dbec5..213ac3d9f950 100644 --- a/arch/xtensa/Kconfig +++ b/arch/xtensa/Kconfig @@ -103,6 +103,35 @@ config MATH_EMULATION help Can we use information of configuration file? +config INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX + bool "Initialize Xtensa MMU inside the Linux kernel code" + default y + help + Earlier version initialized the MMU in the exception vector + before jumping to _startup in head.S and had an advantage that + it was possible to place a software breakpoint at 'reset' and + then enter your normal kernel breakpoints once the MMU was mapped + to the kernel mappings (0XC0000000). + + This unfortunately doesn't work for U-Boot and likley also wont + work for using KEXEC to have a hot kernel ready for doing a + KDUMP. + + So now the MMU is initialized in head.S but it's necessary to + use hardware breakpoints (gdb 'hbreak' cmd) to break at _startup. + xt-gdb can't place a Software Breakpoint in the 0XD region prior + to mapping the MMU and after mapping even if the area of low memory + was mapped gdb wouldn't remove the breakpoint on hitting it as the + PC wouldn't match. Since Hardware Breakpoints are recommended for + Linux configurations it seems reasonable to just assume they exist + and leave this older mechanism for unfortunate souls that choose + not to follow Tensilica's recommendation. + + Selecting this will cause U-Boot to set the KERNEL Load and Entry + address at 0x00003000 instead of the mapped std of 0xD0003000. + + If in doubt, say Y. + endmenu config XTENSA_CALIBRATE_CCOUNT |