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