The Xtensa processor architecture is a configurable, extensible, and synthesizable 32-bit RISC processor core provided by Cadence. This is the first part of the basic architecture port with changes to common files. The 'arch/xtensa' directory, and boards and additional drivers will be in separate commits. Signed-off-by: Chris Zankel <chris@zankel.net> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>master
Chris Zankel
8 years ago
committed by
Tom Rini
parent
f225d39d30
commit
de5e5cea02
@ -0,0 +1,97 @@ |
||||
U-Boot for the Xtensa Architecture |
||||
================================== |
||||
|
||||
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 |
||||
Loading…
Reference in new issue