xtensa.rst 4.2 KB

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