Linux kernel expects certain information on the hardware that it runs on. For kernels compiled with ARCH=powerpc,the flattened device tree is the only supported way of booting ARCH=powerpc kernels on non Open Firmware machines,this information has the form of a device tree, which is based on the Open Firmware specification. Bootloaders like U-Boot that do not implement the Open Firmware API, are expected to pass to the kernel a binary form of the flattened device tree, commonly referred to as FDT blob or simply the blob.
http://ozlabs.org/pipermail/linuxppc-dev/2005-August/019362.html
On systems with open firmware, the boot is separated into two phases.In the first phase, OF is still active.
The kernel is not based at physical address 0, and can do OF client calls. In the second phase,
the kernel is based at physical address 0 and OF's memory has been reclaimed by the kernel.
The flattened device tree is the main data structure that is passed from the first phase to the second.
One of the first things that the second phase does is to expand the flattened device tree into the
normal in-kernel device tree representation (a tree of struct device_node).
http://ozlabs.org/pipermail/linuxppc-dev/2005-August/019362.html
-----------------------------------------------------------------------
At OLS I discussed the idea of merging the ppc32 and ppc64
architectures in the Linux kernel with various ppc32 and ppc64 kernel
hackers and users. There was broad agreement that this would be a
good thing to do, so we are going to go ahead and do it.
The plan is to create include/asm-powerpc and arch/powerpc directories
for the merged architecture and move stuff in there as it gets
merged. The existing ppc32 and ppc64 directories will stay around
until they are no longer useful. The intention is not to break
anything that currently works; however, we do not plan to move unused
and unmaintained platforms into the merged architecture.
The advantage of merging is that it will reduce the maintenance effort
and reduce the instances where a common bug gets fixed in one
architecture but not the other. It will also make it easier to
support 64-bit embedded systems as they become more common.
I don't see the merge as changing the actual code that gets executed
on any given platform very much, except in one respect: we are going
to standardize on a flattened device tree as the way that information
about the platform gets passed from the boot loader to the kernel.
Comments? Flames? :)
Paul.
-----------------------------------------------------------------------
>>>> I don't see the merge as changing the actual code that gets executed
>>>> on any given platform very much, except in one respect: we are going
>>>> to standardize on a flattened device tree as the way that
>>>> information
>>>> about the platform gets passed from the boot loader to the kernel.
>
> ^^^^^^^^^^^^^^^^^^^^^***********^^^^^^^^******^
Yes, and that is exactly what I do not want. We are not going
to require OF implementations that do not need yaboot or similar
to pass a flattened device tree to the kernel, eh? Also, there
is no reason why something like yaboot (with an OF still running
underneath) should have to care about anything device-tree related
at all; the OS can just as easily ask the OF itself.
Segher
-----------------------------------------------------------------------
Segher Boessenkool writes:
> Yes, and that is exactly what I do not want. We are not going
> to require OF implementations that do not need yaboot or similar
> to pass a flattened device tree to the kernel, eh? Also, there
> is no reason why something like yaboot (with an OF still running
> underneath) should have to care about anything device-tree related
> at all; the OS can just as easily ask the OF itself.
For now the kernel will cope with either having an OF client interface
entry point or a flattened device tree passed to it. In the future we
intend to move all the OF client calls into the zImage wrapper and
have the zImage wrapper pass the flattened device tree to the kernel
proper. That will be much cleaner because we will be able to get rid
of all of the dodgy RELOC stuff in prom_init.c.
It is already the case (and has always been the case) that you can't
boot a vmlinux image directly from OF - there is always either or both
of yaboot or a zImage wrapper in between anyway.
Paul.
-----------------------------------------------------------------------
http://ozlabs.org/pipermail/linuxppc-dev/2005-August/019408.html
