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. 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). 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. 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. 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. 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, uncompressing and performing several architecture init functions. For i.MX that means pulling every iomux table into U-Boot. For anything 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.. 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? :) -- Matt Sealey <m...@genesi-usa.com> Product Development Analyst, Genesi USA, Inc. On Sun, Apr 3, 2011 at 11:14 AM, Andy Green <a...@warmcat.com> wrote: > On 04/03/2011 05:05 PM, Somebody in the thread at some point said: > >> Above everything else, I definitely like to see DT get done first, >> it's essential for SoC these days. > > All I am suggesting is bind the DTs in the kernel. That's easier and faster > than the alternatives and there is a lot less to go wrong and make DT a > difficult experience for users. > > -Andy > > _______________________________________________ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
