History log of /linux-master/arch/xtensa/include/asm/vectors.h
Revision Date Author Comments
# 5e4417f9 31-Jan-2020 Max Filippov <jcmvbkbc@gmail.com>

xtensa: reorganize vectors placement

Allow vectors to be either merged into the kernel .text or put at a
fixed virtual address independently of XIP option. Drop option that
puts vectors at a fixed offset from the kernel text. Add choice to
Kconfig.
Vectors at fixed virtual address may be useful for XIP-aware MTD support
and for noMMU configurations with available IRAM. Configurations without
VECBASE register must put their vectors at specific locations regardless
of the selected option. All other configurations should happily use
merged vectors.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# a922b156 31-Jan-2020 Max Filippov <jcmvbkbc@gmail.com>

xtensa: clean up optional XCHAL_* definitions

Simplify users of XCHAL_HAVE_EXTERN_REGS and XCHAL_HAVE_VECBASE and
always define them as 0 if they're not defined in the variant/core.h

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# 7af710d9 03-Jan-2017 Max Filippov <jcmvbkbc@gmail.com>

xtensa: add XIP kernel support

XIP (eXecute In Place) kernel image is the image that can be run
directly from ROM, using RAM only for writable data.

XIP xtensa kernel differs from regular xtensa kernel in the following
ways:
- it has exception/IRQ vectors merged into text section. No vectors
relocation takes place at kernel startup.
- .data/.bss location must be specified in the kernel configuration,
its content is copied there in the _startup function.
- .init.text is merged with the rest of text and is executed from ROM.
- when MMU is used the virtual address where the kernel will be mapped
must be specified in the kernel configuration. It may be in the KSEG
or in the KIO, __pa macro is adjusted to be able to handle both.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# 6591685d 27-Sep-2019 Max Filippov <jcmvbkbc@gmail.com>

xtensa: move XCHAL_KIO_* definitions to kmem_layout.h

These address and size definitions define xtensa kernel memory layout,
move them from vectors.h to the kmem_layout.h

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# 8f8d5745 01-Jan-2019 Max Filippov <jcmvbkbc@gmail.com>

xtensa: replace variant/core.h with asm/core.h

Introduce the header arch/xtensa/include/asm/core.h that provides
definitions for XCHAL macros missing in older xtensa releases. Use this
header instead of variant/core.h

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# fc862ee9 13-Aug-2018 Max Filippov <jcmvbkbc@gmail.com>

xtensa: drop unneeded platform/hardware.h headers

platform/hardware.h no longer supply any information for processor.h,
vectors.h, setup.c or vmlinux.lds.S, don't include it.
This header is now empty in the platforms/iss, so remove it altogether.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# b46dcfa3 04-Jan-2017 Max Filippov <jcmvbkbc@gmail.com>

xtensa: allow merging vectors into .text section

Currently code for exception/IRQ vectors is stored in kernel image as
initialization data and is copied to its working addresses during
startup. It doesn't always make sense. In many cases vectors location
can be automatically decided at kernel link time and code can be placed
right there. This is especially useful for XIP kernel.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# a9f2fc62 12-Apr-2016 Max Filippov <jcmvbkbc@gmail.com>

xtensa: cleanup MMU setup and kernel layout macros

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 <jcmvbkbc@gmail.com>


# f1883aa7 11-Apr-2016 Max Filippov <jcmvbkbc@gmail.com>

xtensa: move kernel mapping addresses into kmem_layout.h

Create a header dedicated to memory layout definitions. Include it from
places where these definitions are needed.
Express vmalloc area address, VIRTUAL_MEMORY_ADDRESS and KERNELOFFSET
through KSEG address.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# 0d848afe 16-Oct-2015 Max Filippov <jcmvbkbc@gmail.com>

xtensa: drop unused sections and remapped reset handlers

There are no .bootstrap or .ResetVector.text sections linked to the
vmlinux image, drop these sections from vmlinux.ld.S. Drop
RESET_VECTOR_VADDR definition only used for .ResetVector.text.

Drop remapped copies of primary and secondary reset vectors, as modern
gdb don't have problems stepping through instructions at arbitrary
locations. Drop corresponding sections from the corresponding linker
scripts.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# ab45fb14 16-Oct-2015 Max Filippov <jcmvbkbc@gmail.com>

xtensa: fix secondary core boot in SMP

There are multiple factors adding to the issue in different
configurations:

- commit 17290231df16eeee ("xtensa: add fixup for double exception raised
in window overflow") added function window_overflow_restore_a0_fixup to
double exception vector overlapping reset vector location of secondary
processor cores.
- on MMUv2 cores RESET_VECTOR1_VADDR may point to uncached kernel memory
making code overlapping depend on cache type and size, so that without
cache or with WT cache reset vector code overwrites double exception
code, making issue even harder to detect.
- on MMUv3 cores RESET_VECTOR1_VADDR may point to unmapped area, as
MMUv3 cores change virtual address map to match MMUv2 layout, but
reset vector virtual address is given for the original MMUv3 mapping.
- physical memory region of the secondary reset vector is not reserved
in the physical memory map, and thus may be allocated and overwritten
at arbitrary moment.

Fix it as follows:

- move window_overflow_restore_a0_fixup code to .text section.
- define RESET_VECTOR1_VADDR so that it points to reset vector in the
cacheable MMUv2 map for cores with MMU.
- reserve reset vector region in the physical memory map. Drop separate
literal section and build mxhead.S with text section literals.

Cc: <stable@vger.kernel.org>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# 260c64bb 24-Sep-2015 Max Filippov <jcmvbkbc@gmail.com>

xtensa: nommu: provide correct KIO addresses

KIO region location is different for noMMU cores. Provide different
default physical address and make KIO virtual address equal to physical.

Move xtensa_get_kio_paddr function close to XCHAL_KIO_PADDR definition
and define it not only for MMUv3, but for all MMU options except MMUv2.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# 72bb305f 02-Oct-2014 Max Filippov <jcmvbkbc@gmail.com>

xtensa: nommu: fix load address definitions

Change KERNELOFFSET, LOAD_MEMORY_ADDRESS and VIRTUAL_MEMORY_ADDRESS to be
relative to the start of physical memory in noMMU configuration, as
there's no uniform memory remapping to KSEG starting at 0xd0000000.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# 9848e49a 15-Jan-2014 Max Filippov <jcmvbkbc@gmail.com>

xtensa: fix warning '"CONFIG_OF" is not defined'

The warning only shows up when building MMUv3 configuration with OF
support disabled.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# 6cb97111 29-Dec-2013 Baruch Siach <baruch@tkos.co.il>

xtensa: remap io area defined in device tree

Use the simple-bus node to discover the io area, and remap the cached and
bypass io ranges. The parent-bus-address value of the first triplet in the
"ranges" property is used. This value is rounded down to the nearest 256MB
boundary. The length of the io area is fixed at 256MB; the "ranges" property
length value is ignored.

Other limitations: (1) only the first simple-bus node is considered, and (2)
only the first triplet of the "ranges" property is considered.

See ePAPR 1.1 §6.5 for the simple-bus node description, and §2.3.8 for the
"ranges" property description.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# 4809bb46 16-Nov-2013 Baruch Siach <baruch@tkos.co.il>

xtensa: avoid duplicate of IO range definitions

Define IO addresses in a single place, to make it easier to change for
non-standard memory maps.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# f0a34615 18-Nov-2013 Max Filippov <jcmvbkbc@gmail.com>

xtensa: clean up include/asm/vectors.h

- drop unused PHYSICAL_MEMORY_ADDRESS and XC_PADDR
- fix NMI_VECTOR_VADDR and INTLEVEL7_VECTOR_VADDR definitions: there
should be no XCHAL_ prefix in them;
- fix the following warning seen with gcc-4.8.1:

arch/xtensa/include/asm/vectors.h:71:5: warning: "XCHAL_HAVE_VECBASE" is not defined [-Wundef]

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Chris Zankel <chris@zankel.net>


# e85e335f 03-Dec-2012 Max Filippov <jcmvbkbc@gmail.com>

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>