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