bootph.yaml 3.1 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788
  1. # SPDX-License-Identifier: BSD-2-Clause
  2. # Copyright 2022 Google LLC
  3. %YAML 1.2
  4. ---
  5. $id: http://devicetree.org/schemas/bootph.yaml#
  6. $schema: http://devicetree.org/meta-schemas/core.yaml#
  7. title: Boot-phase-specific device nodes
  8. maintainers:
  9. - Simon Glass <sjg@chromium.org>
  10. description: |
  11. Some programs run in memory-constrained environments yet want to make use
  12. of device tree.
  13. The full device tree is often quite large relative to the available memory
  14. of a boot phase, so cannot fit into every phase of the boot process. Even
  15. when memory is not a problem, some phases may wish to limit which device
  16. nodes are present, so as to reduce execution time.
  17. This binding supports adding tags to device tree nodes to allow them to be
  18. marked according to the phases where they should be included.
  19. Without any tags, nodes are included only in the final phase, where all
  20. memory is available. Any untagged nodes are dropped from previous phases
  21. and are ignored before the final phase is reached.
  22. The build process produces a separate executable for each phase. It can
  23. use fdtgrep to drop any nodes which are not needed for a particular build.
  24. For example, the pre-sram build will drop any nodes which are not marked
  25. with bootph-pre-sram or bootph-all tags.
  26. Note that phase builds may drop the tags, since they have served their
  27. purpose by that point. So when looking at phase-specific device tree files
  28. you may not see these tags.
  29. Multiple tags can be used in the same node.
  30. Tags in a child node are implied to be present in all parent nodes as well.
  31. This is important, since some missing properties (such as "ranges", or
  32. "compatible") can cause the child node to be ignored or incorrectly
  33. parsed.
  34. That said, at present, fdtgrep applies tags only to the node they are
  35. added to, not to any parents. This means U-Boot device tree files often
  36. add the same tag to parent nodes, rather than relying on tooling to do
  37. this. This is a limitation of fdtgrep and it will be addressed so that
  38. 'Linux DTs' do not need to do this.
  39. The available tags are described as properties below, in order of phase
  40. execution.
  41. select: true
  42. properties:
  43. bootph-pre-sram:
  44. type: boolean
  45. description:
  46. Enable this node when SRAM is not available. This phase must set up
  47. some SRAM or cache-as-RAM so it can obtain data/BSS space to use
  48. during execution.
  49. bootph-verify:
  50. type: boolean
  51. description:
  52. Enable this node in the verification step, which decides which of the
  53. available images should be run next.
  54. bootph-pre-ram:
  55. type: boolean
  56. description:
  57. Enable this node in the phase that sets up SDRAM.
  58. bootph-some-ram:
  59. type: boolean
  60. description:
  61. Enable this node in the phase that is run after SDRAM is working but
  62. before all of it is available. Some RAM is available but it is limited
  63. (e.g. it may be split into two pieces by the location of the running
  64. program) because the program code is not yet relocated out of the way.
  65. bootph-all:
  66. type: boolean
  67. description:
  68. Include this node in all phases (for U-Boot see enum u_boot_phase).
  69. additionalProperties: true