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