Chris Zankel | de5e5ce | 2016-08-10 18:36:43 +0300 | [diff] [blame] | 1 | U-Boot for the Xtensa Architecture |
| 2 | ================================== |
| 3 | |
| 4 | Xtensa Architecture and Diamond Cores |
| 5 | ------------------------------------- |
| 6 | |
| 7 | Xtensa is a configurable processor architecture from Tensilica, Inc. |
| 8 | Diamond Cores are pre-configured instances available for license and |
| 9 | SoC cores in the same manner as ARM, MIPS, etc. |
| 10 | |
| 11 | Xtensa licensees create their own Xtensa cores with selected features |
| 12 | and custom instructions, registers and co-processors. The custom core |
| 13 | is configured with Tensilica tools and built with Tensilica's Xtensa |
| 14 | Processor Generator. |
| 15 | |
| 16 | There are an effectively infinite number of CPUs in the Xtensa |
| 17 | architecture family. It is, however, not feasible to support individual |
| 18 | Xtensa CPUs in U-Boot. Therefore, there is only a single 'xtensa' CPU |
| 19 | in the cpu tree of U-Boot. |
| 20 | |
| 21 | In the same manner as the Linux port to Xtensa, U-Boot adapts to an |
| 22 | individual Xtensa core configuration using a set of macros provided with |
| 23 | the particular core. This is part of what is known as the hardware |
| 24 | abstraction layer (HAL). For the purpose of U-Boot, the HAL consists only |
| 25 | of a few header files. These provide CPP macros that customize sources, |
| 26 | Makefiles, and the linker script. |
| 27 | |
| 28 | |
| 29 | Adding support for an additional processor configuration |
| 30 | -------------------------------------------------------- |
| 31 | |
| 32 | The header files for one particular processor configuration are inside |
| 33 | a variant-specific directory located in the arch/xtensa/include/asm |
| 34 | directory. The name of that directory starts with 'arch-' followed by |
| 35 | the name for the processor configuration, for example, arch-dc233c for |
| 36 | the Diamond DC233 processor. |
| 37 | |
| 38 | core.h Definitions for the core itself. |
| 39 | |
| 40 | The following files are part of the overlay but not used by U-Boot. |
| 41 | |
| 42 | tie.h Co-processors and custom extensions defined |
| 43 | in the Tensilica Instruction Extension (TIE) |
| 44 | language. |
| 45 | tie-asm.h Assembly macros to access custom-defined registers |
| 46 | and states. |
| 47 | |
| 48 | |
| 49 | Global Data Pointer, Exported Function Stubs, and the ABI |
| 50 | --------------------------------------------------------- |
| 51 | |
| 52 | To support standalone applications launched with the "go" command, |
| 53 | U-Boot provides a jump table of entrypoints to exported functions |
| 54 | (grep for EXPORT_FUNC). The implementation for Xtensa depends on |
| 55 | which ABI (or function calling convention) is used. |
| 56 | |
| 57 | Windowed ABI presents unique difficulties with the approach based on |
| 58 | keeping global data pointer in dedicated register. Because the register |
| 59 | window rotates during a call, there is no register that is constantly |
| 60 | available for the gd pointer. Therefore, on xtensa gd is a simple |
| 61 | global variable. Another difficulty arises from the requirement to have |
| 62 | an 'entry' at the beginning of a function, which rotates the register |
| 63 | file and reserves a stack frame. This is an integral part of the |
| 64 | windowed ABI implemented in hardware. It makes using a jump table to an |
| 65 | arbitrary (separately compiled) function a bit tricky. Use of a simple |
| 66 | wrapper is also very tedious due to the need to move all possible |
| 67 | register arguments and adjust the stack to handle arguments that cannot |
| 68 | be passed in registers. The most efficient approach is to have the jump |
| 69 | table perform the 'entry' so as to pretend it's the start of the real |
| 70 | function. This requires decoding the target function's 'entry' |
| 71 | instruction to determine the stack frame size, and adjusting the stack |
| 72 | pointer accordingly, then jumping into the target function just after |
| 73 | the 'entry'. Decoding depends on the processor's endianness so uses the |
| 74 | HAL. The implementation (12 instructions) is in examples/stubs.c. |
| 75 | |
| 76 | |
| 77 | Access to Invalid Memory Addresses |
| 78 | ---------------------------------- |
| 79 | |
| 80 | U-Boot does not check if memory addresses given as arguments to commands |
| 81 | such as "md" are valid. There are two possible types of invalid |
| 82 | addresses: an area of physical address space may not be mapped to RAM |
| 83 | or peripherals, or in the presence of MMU an area of virtual address |
| 84 | space may not be mapped to physical addresses. |
| 85 | |
| 86 | Accessing first type of invalid addresses may result in hardware lockup, |
| 87 | reading of meaningless data, written data being ignored or an exception, |
| 88 | depending on the CPU wiring to the system. Accessing second type of |
| 89 | invalid addresses always ends with an exception. |
| 90 | |
| 91 | U-Boot for Xtensa provides a special memory exception handler that |
| 92 | reports such access attempts and resets the board. |
| 93 | |
| 94 | |
| 95 | ------------------------------------------------------------------------------ |
| 96 | Chris Zankel |
| 97 | Ross Morley |