mirror of
https://github.com/AsahiLinux/u-boot
synced 2024-11-05 20:54:31 +00:00
de5e5cea02
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>
97 lines
4.3 KiB
Text
97 lines
4.3 KiB
Text
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
|