DeviceTree Booting¶
During the development of the Linux/ppc64 kernel, and more specifically, theaddition of new platform types outside of the old IBM pSeries/iSeries pair, itwas decided to enforce some strict rules regarding the kernel entry andbootloader <-> kernel interfaces, in order to avoid the degeneration that hadbecome the ppc32 kernel entry point and the way a new platform should be addedto the kernel. The legacy iSeries platform breaks those rules as it predatesthis scheme, but no new board support will be accepted in the main tree thatdoesn’t follow them properly. In addition, since the advent of the arch/powerpcmerged architecture for ppc32 and ppc64, new 32-bit platforms and 32-bitplatforms which move into arch/powerpc will be required to use these rules aswell.
The main requirement that will be defined in more detail below is the presenceof a device-tree whose format is defined after Open Firmware specification.However, in order to make life easier to embedded board vendors, the kerneldoesn’t require the device-tree to represent every device in the system and onlyrequires some nodes and properties to be present. For example, the kernel doesnot require you to create a node for every PCI device in the system. It is arequirement to have a node for PCI host bridges in order to provide interruptrouting information and memory/IO ranges, among others. It is also recommendedto define nodes for on chip devices and other buses that don’t specifically fitin an existing OF specification. This creates a great flexibility in the way thekernel can then probe those and match drivers to device, without having to hardcode all sorts of tables. It also makes it more flexible for board vendors to dominor hardware upgrades without significantly impacting the kernel code orcluttering it with special cases.
Entry point¶
There is one single entry point to the kernel, at the startof the kernel image. That entry point supports two callingconventions:
a) Boot from Open Firmware. If your firmware is compatiblewith Open Firmware (IEEE 1275) or provides an OF compatibleclient interface API (support for “interpret” callback offorth words isn’t required), you can enter the kernel with:
r5 : OF callback pointer as defined by IEEE 1275bindings to powerpc. Only the 32-bit client interfaceis currently supported
r3, r4 : address & length of an initrd if any or 0
The MMU is either on or off; the kernel will run thetrampoline located in arch/powerpc/kernel/prom_init.c toextract the device-tree and other information from openfirmware and build a flattened device-tree as describedin b).
prom_init()will then re-enter the kernel usingthe second method. This trampoline code runs in thecontext of the firmware, which is supposed to handle allexceptions during that time.b) Direct entry with a flattened device-tree block. This entrypoint is called by a) after the OF trampoline and can also becalled directly by a bootloader that does not support the OpenFirmware client interface. It is also used by “kexec” toimplement “hot” booting of a new kernel from a previousrunning one. This method is what I will describe in moredetails in this document, as method a) is simply standard OpenFirmware, and thus should be implemented according to thevarious standard documents defining it and its binding to thePowerPC platform. The entry point definition then becomes:
r3 : physical pointer to the device-tree block(defined in chapter II) in RAM
r4 : physical pointer to the kernel itself. This isused by the assembly code to properly disable the MMUin case you are entering the kernel with MMU enabledand a non-1:1 mapping.
r5 : NULL (as to differentiate with method a)
Note about SMP entry: Either your firmware puts your otherCPUs in some sleep loop or spin loop in ROM where you can getthem out via a soft reset or some other means, in which caseyou don’t need to care, or you’ll have to enter the kernelwith all CPUs. The way to do that with method b) will bedescribed in a later revision of this document.
Board supports (platforms) are not exclusive config options. Anarbitrary set of board supports can be built in a single kernelimage. The kernel will “know” what set of functions to use for agiven platform based on the content of the device-tree. Thus, youshould:
a) add your platform support as a _boolean_ option inarch/powerpc/Kconfig, following the example of PPC_PSERIESand PPC_PMAC. The latter is probably a goodexample of a board support to start from.
b) create your main platform file as“arch/powerpc/platforms/myplatform/myboard_setup.c” and add itto the Makefile under the condition of your
CONFIG_option. This file will define a structure of type “ppc_md”containing the various callbacks that the generic code willuse to get to your platform specific code
A kernel image may support multiple platforms, but only if theplatforms feature the same core architecture. A single kernel buildcannot support both configurations with Book E and configurationswith classic Powerpc architectures.