|
@@ -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
|