| |||||||||||||
KS2010: Development processKS2010: Development processPosted Nov 4, 2010 4:20 UTC (Thu) by swetland (subscriber, #63414)Parent article: KS2010: Development process
I'm perplexed at the desire for device trees.
The idea that you're going to have one kernel that will run on the next spin of the hardware with no changes at all is somewhat laughable in most "real" embedded projects. Things move around and not just simple things like gpio assignments that you can stick in a static structure.
Oops, turns out that you need a level shifter on part of the I2C bus that must be turned on before you initialize the peripherals behind it. Until you start sticking bytecode in your device trees, changes like this will require kernel/driver changes.
Basically device trees make my life harder by putting board configuration in the bootloader or another partition somewhere where it can get out of sync with the kernel.
A lot of people seem to want embedded to look like PCs with everything based on (expensive) enumerable busses and (clunky) BIOSes that set up things before booting. This is incompatible with building cost-effective and power-use-competitive hardware in highly competive embedded/mobile spaces.
(Log in to post comments)
KS2010: Development process Posted Nov 4, 2010 11:00 UTC (Thu) by Klavs (subscriber, #10563) [Link]
I'm a bit confused here. You seem to be against BOTH devicetrees and discoverable buses? and if so - what solution do you think is the best for embedded environment?
KS2010: Development process Posted Nov 4, 2010 12:01 UTC (Thu) by swetland (subscriber, #63414) [Link]
I love nice enumerable busses -- I just almost never have the luxury of them existing on the embedded platforms I work with. In their absence, I find the existing board/machine file mechanism Linux uses gets the job done and without having to depend on fragile links between data structures embedded in the bootloader or elsewhere and the kernel.
I'd be happy to see improvements to make it easier to maintain board files and such -- they can get a little unwieldy -- but I'm not convinced that a device tree approach actually improves the situation.
I've never worked on a production device (typically shipping between hundreds of thousands and millions of units) where having to compile a new kernel to pick up device-specific hardware support is the major pain point. Certainly I never have a canned, existing kernel that I'm going to just use with no modifications -- power tuning and debugging during stabilization guarantees that we're going to be spinning quite a few kernel builds until things are ready to ship.
KS2010: Development process Posted Nov 4, 2010 16:41 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
nobody is expecting that device trees will eliminate the need for you to compile your own kernel for a production system.
it's also not that you will take a kernel compiled for one device and change the devicetree file and load it on another device.
what they will do is make it so that there aren't 70 different subarchitectures in ARM that all have to be tested individually and replace it with a much smaller number with devicetrees identifying the minor details like where a particular piece of hardware is addressed. As such it will make it easier for people to maintain the kernel and make sure that it will work.
|
|||||||||||||