arch/powerpc/booting.rst

1 .. SPDX-License-Identifier: GPL-2.0
4 ------------------
6 During the development of the Linux/ppc64 kernel, and more specifically, the
8 was decided to enforce some strict rules regarding the kernel entry and
9 bootloader <-> kernel interfaces, in order to avoid the degeneration that had
10 become the ppc32 kernel entry point and the way a new platform should be added
11 to the kernel. The legacy iSeries platform breaks those rules as it predates
12 this scheme, but no new board support will be accepted in the main tree that
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
18 The main requirement that will be defined in more detail below is the presence
19 of a device-tree whose format is defined after Open Firmware specification.
20 However, in order to make life easier to embedded board vendors, the kernel
21 doesn't require the device-tree to represent every device in the system and only
22 requires some nodes and properties to be present. For example, the kernel does
23 not require you to create a node for every PCI device in the system. It is a
24 requirement to have a node for PCI host bridges in order to provide interrupt
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
30 minor hardware upgrades without significantly impacting the kernel code or
37 There is one single entry point to the kernel, at the start
38 of the kernel image. That entry point supports two calling
44         forth words isn't required), you can enter the kernel with:
47               bindings to powerpc. Only the 32-bit client interface
52               The MMU is either on or off; the kernel will run the
53               trampoline located in arch/powerpc/kernel/prom_init.c to
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
57               the second method. This trampoline code runs in the
61         b) Direct entry with a flattened device-tree block. This entry
65         implement "hot" booting of a new kernel from a previous
66         running one. This method is what I will describe in more
67         details in this document, as method a) is simply standard Open
72                 r3 : physical pointer to the device-tree block
73                 (defined in chapter II) in RAM
75                 r4 : physical pointer to the kernel itself. This is
77                 in case you are entering the kernel with MMU enabled
78                 and a non-1:1 mapping.
83 CPUs in some sleep loop or spin loop in ROM where you can get
84 them out via a soft reset or some other means, in which case
85 you don't need to care, or you'll have to enter the kernel
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
95         a) add your platform support as a _boolean_ option in
107 A kernel image may support multiple platforms, but only if the
108 platforms feature the same core architecture.  A single kernel build