dt: Remove booting-without-of.rst

booting-without-of.rst is an ancient document that first outlined
Flattened DeviceTree on PowerPC initially. The DT world has evolved a
lot in the 15 years since and booting-without-of.rst is pretty stale.
The name of the document itself is confusing if you don't understand the
evolution from real 'OpenFirmware'. Most of what booting-without-of.rst
contains is now in the DT specification (which evolved out of the
ePAPR). The few things that weren't documented in the DT specification
are now.

All that remains is the boot entry details, so let's move these to arch
specific documents. The exception is arm which already has the same
details documented.

Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Rich Felker <dalias@libc.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-mips@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-sh@vger.kernel.org
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Signed-off-by: Rob Herring <robh@kernel.org>
This commit is contained in:
Rob Herring 2020-10-08 09:24:20 -05:00
parent 588614be61
commit 441848282c
10 changed files with 175 additions and 1586 deletions

File diff suppressed because it is too large Load diff

View file

@ -15,4 +15,3 @@ Open Firmware and Device Tree
overlay-notes
bindings/index
booting-without-of

View file

@ -0,0 +1,28 @@
.. SPDX-License-Identifier: GPL-2.0
BMIPS DeviceTree Booting
------------------------
Some bootloaders only support a single entry point, at the start of the
kernel image. Other bootloaders will jump to the ELF start address.
Both schemes are supported; CONFIG_BOOT_RAW=y and CONFIG_NO_EXCEPT_FILL=y,
so the first instruction immediately jumps to kernel_entry().
Similar to the arch/arm case (b), a DT-aware bootloader is expected to
set up the following registers:
a0 : 0
a1 : 0xffffffff
a2 : Physical pointer to the device tree block (defined in chapter
II) in RAM. The device tree can be located anywhere in the first
512MB of the physical address space (0x00000000 - 0x1fffffff),
aligned on a 64 bit boundary.
Legacy bootloaders do not use this convention, and they do not pass in a
DT block. In this case, Linux will look for a builtin DTB, selected via
CONFIG_DT_*.
This convention is defined for 32-bit systems only, as there are not
currently any 64-bit BMIPS implementations.

View file

@ -8,6 +8,7 @@ MIPS-specific Documentation
:maxdepth: 2
:numbered:
booting
ingenic-tcu
.. only:: subproject and html

View file

@ -0,0 +1,110 @@
.. SPDX-License-Identifier: GPL-2.0
DeviceTree Booting
------------------
During the development of the Linux/ppc64 kernel, and more specifically, the
addition of new platform types outside of the old IBM pSeries/iSeries pair, it
was decided to enforce some strict rules regarding the kernel entry and
bootloader <-> kernel interfaces, in order to avoid the degeneration that had
become the ppc32 kernel entry point and the way a new platform should be added
to the kernel. The legacy iSeries platform breaks those rules as it predates
this scheme, but no new board support will be accepted in the main tree that
doesn't follow them properly. In addition, since the advent of the arch/powerpc
merged architecture for ppc32 and ppc64, new 32-bit platforms and 32-bit
platforms which move into arch/powerpc will be required to use these rules as
well.
The main requirement that will be defined in more detail below is the presence
of a device-tree whose format is defined after Open Firmware specification.
However, in order to make life easier to embedded board vendors, the kernel
doesn't require the device-tree to represent every device in the system and only
requires some nodes and properties to be present. For example, the kernel does
not require you to create a node for every PCI device in the system. It is a
requirement to have a node for PCI host bridges in order to provide interrupt
routing information and memory/IO ranges, among others. It is also recommended
to define nodes for on chip devices and other buses that don't specifically fit
in an existing OF specification. This creates a great flexibility in the way the
kernel can then probe those and match drivers to device, without having to hard
code all sorts of tables. It also makes it more flexible for board vendors to do
minor hardware upgrades without significantly impacting the kernel code or
cluttering it with special cases.
Entry point
~~~~~~~~~~~
There is one single entry point to the kernel, at the start
of the kernel image. That entry point supports two calling
conventions:
a) Boot from Open Firmware. If your firmware is compatible
with Open Firmware (IEEE 1275) or provides an OF compatible
client interface API (support for "interpret" callback of
forth words isn't required), you can enter the kernel with:
r5 : OF callback pointer as defined by IEEE 1275
bindings to powerpc. Only the 32-bit client interface
is currently supported
r3, r4 : address & length of an initrd if any or 0
The MMU is either on or off; the kernel will run the
trampoline located in arch/powerpc/kernel/prom_init.c to
extract the device-tree and other information from open
firmware and build a flattened device-tree as described
in b). prom_init() will then re-enter the kernel using
the second method. This trampoline code runs in the
context of the firmware, which is supposed to handle all
exceptions during that time.
b) Direct entry with a flattened device-tree block. This entry
point is called by a) after the OF trampoline and can also be
called directly by a bootloader that does not support the Open
Firmware client interface. It is also used by "kexec" to
implement "hot" booting of a new kernel from a previous
running one. This method is what I will describe in more
details in this document, as method a) is simply standard Open
Firmware, and thus should be implemented according to the
various standard documents defining it and its binding to the
PowerPC 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 is
used by the assembly code to properly disable the MMU
in case you are entering the kernel with MMU enabled
and a non-1:1 mapping.
r5 : NULL (as to differentiate with method a)
Note about SMP entry: Either your firmware puts your other
CPUs in some sleep loop or spin loop in ROM where you can get
them out via a soft reset or some other means, in which case
you don't need to care, or you'll have to enter the kernel
with all CPUs. The way to do that with method b) will be
described in a later revision of this document.
Board supports (platforms) are not exclusive config options. An
arbitrary set of board supports can be built in a single kernel
image. The kernel will "know" what set of functions to use for a
given platform based on the content of the device-tree. Thus, you
should:
a) add your platform support as a _boolean_ option in
arch/powerpc/Kconfig, following the example of PPC_PSERIES,
PPC_PMAC and PPC_MAPLE. The later is probably a good
example of a board support to start from.
b) create your main platform file as
"arch/powerpc/platforms/myplatform/myboard_setup.c" and add it
to 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 will
use to get to your platform specific code
A kernel image may support multiple platforms, but only if the
platforms feature the same core architecture. A single kernel build
cannot support both configurations with Book E and configurations
with classic Powerpc architectures.

View file

@ -7,6 +7,7 @@ powerpc
.. toctree::
:maxdepth: 1
booting
bootwrapper
cpu_families
cpu_features

View file

@ -0,0 +1,12 @@
.. SPDX-License-Identifier: GPL-2.0
DeviceTree Booting
------------------
Device-tree compatible SH bootloaders are expected to provide the physical
address of the device tree blob in r4. Since legacy bootloaders did not
guarantee any particular initial register state, kernels built to
inter-operate with old bootloaders must either use a builtin DTB or
select a legacy board option (something other than CONFIG_SH_DEVICE_TREE)
that does not use device tree. Support for the latter is being phased out
in favor of device tree.

View file

@ -7,6 +7,7 @@ SuperH Interfaces Guide
.. toctree::
:maxdepth: 1
booting
new-machine
register-banks

View file

@ -0,0 +1,21 @@
.. SPDX-License-Identifier: GPL-2.0
DeviceTree Booting
------------------
There is one single 32bit entry point to the kernel at code32_start,
the decompressor (the real mode entry point goes to the same 32bit
entry point once it switched into protected mode). That entry point
supports one calling convention which is documented in
Documentation/x86/boot.rst
The physical pointer to the device-tree block is passed via setup_data
which requires at least boot protocol 2.09.
The type filed is defined as
#define SETUP_DTB 2
This device-tree is used as an extension to the "boot page". As such it
does not parse / consider data which is already covered by the boot
page. This includes memory size, reserved ranges, command line arguments
or initrd address. It simply holds information which can not be retrieved
otherwise like interrupt routing or a list of devices behind an I2C bus.

View file

@ -9,6 +9,7 @@ x86-specific Documentation
:numbered:
boot
booting-dt
topology
exception-tables
kernel-stacks