123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899 |
- .. SPDX-License-Identifier: GPL-2.0+
- Xtensa
- ======
- Xtensa Architecture and Diamond Cores
- -------------------------------------
- Xtensa is a configurable processor architecture from Tensilica, Inc.
- Diamond Cores are pre-configured instances available for license and
- SoC cores in the same manner as ARM, MIPS, etc.
- Xtensa licensees create their own Xtensa cores with selected features
- and custom instructions, registers and co-processors. The custom core
- is configured with Tensilica tools and built with Tensilica's Xtensa
- Processor Generator.
- There are an effectively infinite number of CPUs in the Xtensa
- architecture family. It is, however, not feasible to support individual
- Xtensa CPUs in U-Boot. Therefore, there is only a single 'xtensa' CPU
- in the cpu tree of U-Boot.
- In the same manner as the Linux port to Xtensa, U-Boot adapts to an
- individual Xtensa core configuration using a set of macros provided with
- the particular core. This is part of what is known as the hardware
- abstraction layer (HAL). For the purpose of U-Boot, the HAL consists only
- of a few header files. These provide CPP macros that customize sources,
- Makefiles, and the linker script.
- Adding support for an additional processor configuration
- --------------------------------------------------------
- The header files for one particular processor configuration are inside
- a variant-specific directory located in the arch/xtensa/include/asm
- directory. The name of that directory starts with 'arch-' followed by
- the name for the processor configuration, for example, arch-dc233c for
- the Diamond DC233 processor.
- core.h:
- Definitions for the core itself.
- The following files are part of the overlay but not used by U-Boot.
- tie.h:
- Co-processors and custom extensions defined in the Tensilica Instruction
- Extension (TIE) language.
- tie-asm.h:
- Assembly macros to access custom-defined registers and states.
- Global Data Pointer, Exported Function Stubs, and the ABI
- ---------------------------------------------------------
- To support standalone applications launched with the "go" command,
- U-Boot provides a jump table of entrypoints to exported functions
- (grep for EXPORT_FUNC). The implementation for Xtensa depends on
- which ABI (or function calling convention) is used.
- Windowed ABI presents unique difficulties with the approach based on
- keeping global data pointer in dedicated register. Because the register
- window rotates during a call, there is no register that is constantly
- available for the gd pointer. Therefore, on xtensa gd is a simple
- global variable. Another difficulty arises from the requirement to have
- an 'entry' at the beginning of a function, which rotates the register
- file and reserves a stack frame. This is an integral part of the
- windowed ABI implemented in hardware. It makes using a jump table to an
- arbitrary (separately compiled) function a bit tricky. Use of a simple
- wrapper is also very tedious due to the need to move all possible
- register arguments and adjust the stack to handle arguments that cannot
- be passed in registers. The most efficient approach is to have the jump
- table perform the 'entry' so as to pretend it's the start of the real
- function. This requires decoding the target function's 'entry'
- instruction to determine the stack frame size, and adjusting the stack
- pointer accordingly, then jumping into the target function just after
- the 'entry'. Decoding depends on the processor's endianness so uses the
- HAL. The implementation (12 instructions) is in examples/stubs.c.
- Access to Invalid Memory Addresses
- ----------------------------------
- U-Boot does not check if memory addresses given as arguments to commands
- such as "md" are valid. There are two possible types of invalid
- addresses: an area of physical address space may not be mapped to RAM
- or peripherals, or in the presence of MMU an area of virtual address
- space may not be mapped to physical addresses.
- Accessing first type of invalid addresses may result in hardware lockup,
- reading of meaningless data, written data being ignored or an exception,
- depending on the CPU wiring to the system. Accessing second type of
- invalid addresses always ends with an exception.
- U-Boot for Xtensa provides a special memory exception handler that
- reports such access attempts and resets the board.
- .. Chris Zankel
- .. Ross Morley
|