linux-embedded.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
	linux-arch@vger.kernel.org,
	Josh Boyer <jwboyer@linux.vnet.ibm.com>,
	Tim Bird <tim.bird@am.sony.com>,
	linux-embedded@vger.kernel.org,
	ksummit-2009-discuss@lists.linux-foundation.org
Subject: Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
Date: Wed, 3 Jun 2009 07:53:55 +0100	[thread overview]
Message-ID: <20090603065355.GC23561@linux-mips.org> (raw)
In-Reply-To: <fa686aa40906021029macf3c72g5261f8d4dbea935a@mail.gmail.com>

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

  parent reply	other threads:[~2009-06-03  6:53 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-02 15:22 Representing Embedded Architectures at the Kernel Summit James Bottomley
2009-06-02 17:29 ` Josh Boyer
2009-06-02 17:42   ` James Bottomley
2009-06-02 17:52     ` David VomLehn
2009-06-02 18:25       ` James Bottomley
2009-06-02 18:51         ` Josh Boyer
2009-06-02 19:30           ` Tim Bird
2009-06-02 20:37             ` [Ksummit-2009-discuss] " James Bottomley
2009-06-02 20:44               ` Bill Gatliff
2009-06-02 21:34               ` Robert Schwebel
2009-06-03  3:35                 ` Greg KH
     [not found]                   ` <20090731152617.GW29245@pengutronix.de>
2009-07-31 15:53                     ` flicker free booting Robert Schwebel
2009-07-31 18:03                       ` David VomLehn
2009-07-31 18:09                         ` Robert Schwebel
2009-07-31 18:42                           ` Bill Gatliff
2009-08-03  8:19                             ` Sascha Hauer
2009-08-03  8:37                               ` Geert Uytterhoeven
2009-07-31 18:46                         ` Bill Gatliff
2009-07-31 19:48                           ` Tim Bird
2009-07-31 19:51                             ` Bill Gatliff
2009-07-31 20:05                             ` Robert Schwebel
2009-08-01  1:26                               ` Tim Bird
2009-07-31 19:25                       ` Bill Gatliff
2009-08-01 14:25                         ` Jamie Lokier
2009-06-03  0:03               ` [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit David VomLehn
2009-06-03  0:52                 ` Eric W. Biederman
2009-06-03  1:42                 ` Steven Rostedt
2009-06-02 22:21   ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-03  6:24     ` [Ksummit-2009-discuss] " Ralf Baechle
2009-06-10 23:13     ` Kumar Gala
2009-06-14  3:48       ` Grant Likely
2009-06-10 23:08   ` Kumar Gala
2009-06-02 17:29 ` Grant Likely
2009-06-02 17:45   ` David VomLehn
2009-06-02 18:46     ` Grant Likely
2009-06-02 17:48   ` James Bottomley
2009-06-03 12:17     ` Mark Brown
2009-06-04 18:18     ` Grant Likely
2009-06-02 21:10   ` Russell King
2009-06-02 21:16     ` Bill Gatliff
2009-06-02 21:18     ` Geert Uytterhoeven
2009-06-02 21:40     ` Robert Schwebel
     [not found]     ` <20090602214005.GL32630@pengutronix.de>
2009-06-02 21:48       ` Russell King
     [not found]     ` <10f740e80906021418i1d58f5eer940e7a8ec9fb8b9e@mail.gmail.com>
2009-06-03  7:07       ` [Ksummit-2009-discuss] " Ralf Baechle
2009-06-04 20:08     ` Grant Likely
     [not found]     ` <4A2596B4.3020309@billgatliff.com>
2009-06-04 20:15       ` Grant Likely
     [not found]     ` <3340601010994331832@unknownmsgid>
2009-06-04 20:24       ` Grant Likely
2009-06-03  6:53   ` Ralf Baechle [this message]
2009-06-03 13:04 ` [Ksummit-2009-discuss] " Catalin Marinas
2009-06-03 13:18   ` Josh Boyer
2009-06-03 13:45     ` Catalin Marinas
2009-06-03 14:11       ` Josh Boyer
2009-06-03 14:06   ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-03 16:19   ` James Bottomley
2009-06-03 17:09     ` Russell King
2009-06-03 18:43       ` Andrew Morton
2009-06-03 19:01         ` James Bottomley
2009-06-04  3:11         ` David VomLehn (dvomlehn)
2009-06-04  3:24           ` Mike Frysinger
2009-06-04  9:23           ` Mel Gorman
2009-06-03 19:08     ` Catalin Marinas
2009-06-10  9:42     ` Thomas Petazzoni
2009-06-16  6:42 ` Mike Rapoport
2009-06-16  8:06   ` Mike Frysinger
2009-06-16 12:19     ` [Ksummit-2009-discuss] " Ralf Baechle
2009-06-17  4:26       ` H. Peter Anvin
2009-06-17 15:04         ` Ralf Baechle
2009-06-17 17:14           ` H. Peter Anvin
2009-06-16 16:06     ` Grant Likely
2009-06-16 18:18       ` Jamie Lokier
2009-06-16 19:28         ` Grant Likely
2009-06-16 20:07           ` Jamie Lokier
2009-06-16 20:10             ` Marcel Holtmann
2009-06-16 21:04             ` Grant Likely
2009-06-18  3:05   ` Paul Mundt
2009-06-17 14:31 ` Kumar Gala
2009-06-18  2:51   ` Paul Mundt
2009-06-19  2:59     ` Kumar Gala
2009-06-19  3:00       ` Paul Mundt
2009-06-19  7:53         ` Kumar Gala

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090603065355.GC23561@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=grant.likely@secretlab.ca \
    --cc=jwboyer@linux.vnet.ibm.com \
    --cc=ksummit-2009-discuss@lists.linux-foundation.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-embedded@vger.kernel.org \
    --cc=tim.bird@am.sony.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).