Re: Device tree vs hardware configurations

From: Sascha Hauer
Date: Thu Sep 25 2014 - 02:42:49 EST

Hi Nikita,

On Tue, Sep 23, 2014 at 09:58:08PM +0400, Nikita Yushchenko wrote:
> Hi
> I'm currently forward-porting a BSP for imx6-based custom board from
> pre-devicetree kernel to modern kernel.
> In old BSP there was a board setup file, that registered all board's
> devices. For new BSP, I need to replace that with device tree based
> solution.
> However, old BSP used conditional code to register devices
> differently based on GPIO inputs and on kernel command line. This
> approach was used to
> - handle board's jumper that switches SPI CS lines: current jumper
> setting is available over gpio, depending on that old BSP registered
> chips differently,
> - handle different i2c connections on different board revisions:
> board has 5 i2c busses with quite a few devices connected, these
> busses are routed to different hardware busses on different board
> revisions, board revision could be read over gpios.
> - handle different possible display connections (lvds vs lcd, 6bit
> vs 8bit hw interface) based on kernel command line options
> - handle different possible camera connections by registered camera
> differently based on kernel command line option
> ... and more,
> Device tree describes hardware unconditionally. I already have to
> provide 2 dts files for imx6q and imx6dl based setups (both just
> include a common dtsi) ... But providing separate dts file for
> every possible hardware configuration will result into 2^n device
> trees, which is inconvenient visible regression against old BSP that
> "just worked" on all hardware configurations.
> Is there a sane way to handle hardware configurations like above in
> device tree based kernel?

This depends on your definition of sane, but here the options I know of:

- Let the bootloader modify the device tree based on the GPIOs. This
seems doable in new projects, but not when you want to keep the old

- Use device tree overlays in the Kernel which is something Pantelis
Antoniou works on. I think the intention here is more to plug a
daughter board to a CPU board. I don't know how good this works when
you have to manipulate many different places in the device tree.

- I heard people working on a shim to place between bootloader and
kernel. The shim translates the bootloader information into the
device tree. I can't remember who it was though. For going this way
I wouldn't rewrite the shim but use barebox instead of course ;)

BTW where do the command line options in your setup come from? Are
they autogenerated from other informations in the bootloader or are
they entered there by a user?


Pengutronix e.K. | |
Industrial Linux Solutions | |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at