arch/powerpc/booting.rst

1 .. SPDX-License-Identifier: GPL-2.0
3 DeviceTree Booting
4 ------------------
6 During the development of the Linux/ppc64 kernel, and more specifically, the
7 addition of new platform types outside of the old IBM pSeries/iSeries pair, it
9 bootloader <-> kernel interfaces, in order to avoid the degeneration that had
13 doesn't follow them properly.  In addition, since the advent of the arch/powerpc
14 merged architecture for ppc32 and ppc64, new 32-bit platforms and 32-bit
19 of a device-tree whose format is defined after Open Firmware specification.
21 doesn't require the device-tree to represent every device in the system and only
27 in an existing OF specification. This creates a great flexibility in the way the
28 kernel can then probe those and match drivers to device, without having to hard
29 code all sorts of tables. It also makes it more flexible for board vendors to do
30 minor hardware upgrades without significantly impacting the kernel code or
38 of the kernel image. That entry point supports two calling
42         with Open Firmware (IEEE 1275) or provides an OF compatible
43         client interface API (support for "interpret" callback of
46               r5 : OF callback pointer as defined by IEEE 1275
47               bindings to powerpc. Only the 32-bit client interface
50               r3, r4 : address & length of an initrd if any or 0
54               extract the device-tree and other information from open
55               firmware and build a flattened device-tree as described
56               in b). prom_init() will then re-enter the kernel using
58               context of the firmware, which is supposed to handle all
61         b) Direct entry with a flattened device-tree block. This entry
62         point is called by a) after the OF trampoline and can also be
65         implement "hot" booting of a new kernel from a previous
72                 r3 : physical pointer to the device-tree block
78                 and a non-1:1 mapping.
87 described in a later revision of this document.
90 arbitrary set of board supports can be built in a single kernel
91 image. The kernel will "know" what set of functions to use for a
92 given platform based on the content of the device-tree. Thus, you
96         arch/powerpc/Kconfig, following the example of PPC_PSERIES,
98         example of a board support to start from.
102         to the Makefile under the condition of your ``CONFIG_``
103         option. This file will define a structure of type "ppc_md"