On Tue, Jun 02, 2009 at 11:29:46AM -0600, Grant Likely wrote:
> One topic that seems to garner debate is the issue of decoupling the
> kernel image from the target platform. ie. On x86, PowerPC and Sparc
> a kernel image will boot on any machine (assuming the needed drivers
> are enabled), but this is rarely the case in embedded. Most embedded
> kernels require explicit board support selected at compile time with
> no way to produce a generic kernel which will boot on a whole family
> of devices, let alone the whole architecture. Part of this is a
> firmware issue, where existing firmware passes very little in the way
> of hardware description to the kernel, but part is also not making
> available any form of common language for describing the machine.
Hardware is simple to incompatible to allow the generation of a single
"one size fits all" image. To list a few reasons from the MIPS world:
o little vs. big endian
o 32-bit vs. 64-bit
o different system firmwares
o processors and peripherals requiring creative workarounds which for
code size or performance reasons want to limit to those systems
suffering from the issue.
o often claustrophobically small memory sizes.
o exactly no communality across all systems except the processor
architecture.
o vendors coming up with their own instruction set enhancements not
supported by any competitor and insisting on their use for the extra
bit of performance and product differenciation.
o many users have a long standing "roll your own" attitude.
o peripherals that are even less probeable than ISA cards
"Flattened Device Tree" can tackle only a small part of this but its a
step.
> Embedded PowerPC and Microblaze has tackled this problem with the
> "Flattened Device Tree" data format which is derived from the
> OpenFirmware specifications, and there is some interest and debate (as
> discussed recently on the ARM mailing list) about making flattened
> device tree usable by ARM also (which I'm currently
> proof-of-concepting). Josh Boyer has already touched on discussing
> flattened device tree support at kernel summit in an email to the
> ksummit list last week (quoted below), and I'm wondering if a broader
> discussing would be warranted.
Agreed.
Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
