On 04/03/2011 05:46 PM, Somebody in the thread at some point said:
As long as the experience is driven by both the SoC vendor and the
board designer and not the kernel driver engineer, this will go very
well..
At the point where device tree specification and maintenance is done
in-kernel, device trees get very Linux-specific and very
Linux-driver-specific. Plenty of mistakes were made in the move to
flattened device trees on PowerPC which took too long to resolve.
I don't have any comment about who should work on the DT data in-kernel,
whoever would work on it outside kernel should do it in-kernel rendering
this moot.
Linux may not have a stable internal API but the bootloader to kernel
can and should have a stable interface. If that stable interface is
the device tree it cannot change just because someone has the ability
to add 10 lines to a kernel driver AND patch the DT in the same tree
to correspond to it. The device tree is dynamic by design from it's
legacy of OpenPROM and OpenFirmware specification, but that does not
mean it changes every day, it just means it changes depending on
hardware configuration (i.e. plugging a PCI card, showing a USB device
in the tree - even though this is probed later in both cases, if you
boot from it, it should be there. On development boards this is the
presence or not of add-on boards, too, such as LCDs, debug interfaces,
stacks, controllers which may be entirely different per-boot or
per-dip-switch).
I see. That makes DT sound a bit like a hybrid between code and data
that I thought it was meant to eliminate. I guess for board option
case, it should be possible to retain a static definition and have nodes
that are conditional on switch states.
This is a fundamental divergence between consumer product and Linux
developer - it is not acceptable to update the firmware for every
kernel version, or burden the user for responsibility or increase
engineering tasks and risks to make Linux drivers by being reliant on
keeping track of a moving target.
Sounds like we agree about that.
Unfortunately with a predefined, flat device tree compiled at
kernel-time and attached to the kernel image, you lose the
configurability of the hardware and need to at least re-link the
kernel if you remove the debug board, or add a user interface element
like an LCD panel to a pluggable board solution. Or, you have to
specify it in a static tree regardless of presence, and use runtime
code in Linux to specifically detect that this plugin is available,
which defeats the purpose of a device tree in the first place.
I don't see that should follow. You should be able to attached probed
devs to the flat tree basis? It can't do that?
The point: solutions should exist in firmware to generate the device
tree or at least take a known-common configuration and add to it. If
this means making the device tree compiler and an internal API
available within U-Boot, then sure. For real OF or other
implementations (we've been working on a way to interface UEFI with a
device tree for a while using a variant of the system table) this may
be generated in another way.
What you will end up with is two interfaces, like on PPC - one for
flattened trees being loaded from a compiled binary and one which, on
boot, pulls the device tree out to a self-maintained copy which can be
parsed by a common API. This is all already implemented, and common
code across PPC and SPARC and probably Blackfin and the new
architectures.
The interface between U-Boot (to pick an example) to Linux to
basically drop in a device tree when generated by U-Boot itself (or
half-generated or at least compiled at runtime) would still be bootm
with a third argument: that third argument will have to be the pointer
to the generated tree.
My experience with U-Boot and other bootloaders has led me to conclude
they should be as minimal, thin and deterministic as possible. Any real
business should be deferred to Linux doing it in one place and doing it
well.
At the very least any pin configuration - supplemented by a device
tree or otherwise - absolutely must be done in the very first instants
of boot time, and not 5 seconds into kernel boot after loading disks,
Maybe you can explain that with examples where 5 seconds matters that is
not a hardware design error. Because the SoC itself (and I have done
this work for iMX31 in Qi) has default pin states that are usually Hi-Z
with pullup. "First instants" in any case does not sound like a correct
approach either, because if the IO is in conflict even some ms of high
current can't be allowed; your bootloader may crash and your board will
burn. So we can take it that the IO will not be in conflict by default
from startup on any board.
Fact is when the bootloader comes up, you are running OK already by
definition. Voltages, IO, clock for cpu are all an acceptable and safe
starting point that is already running code.
The amount of bringup that truly cannot be deferred to Linux is
restricted only to the prerequisites of loading and booting Linux then,
and that does not involve setting all ball muxes, just the ones involved
in loading and booting Linux.
uncompressing and performing several architecture init functions. For
i.MX that means pulling every iomux table into U-Boot. For anything
No just the genuine prerequisites to get at the kernel and SDRAM.
dynamic (check a GPIO, then change the IOMUX depending on the type of
board, revision or so) then you are forced to think of device trees
anyway..
If you take the approach that the bootloader's job is to do unnecessary
things for loading and booting Linux, it's true there is no end to the
type and scope of things you might try to have the bootloader do.
However in terms of loading and booting Linux, anything outside of that
is unnecessary including "all IOMUX setting", etc.
We are going to have to deal with at least one firmware update for
every "ported" platform. Can we try and keep it to at most one
firmware update for the sake of all our customers? :)
In fact if the machine ID is used as a key to find in-kernel DTs, you
don't need to update the bootloader even once.
-Andy
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
