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