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 98
