linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert.uytterhoeven@gmail.com>
To: Grant Likely <grant.likely@secretlab.ca>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	ksummit-2009-discuss@lists.linux-foundation.org,
	linux-arch@vger.kernel.org, linux-e
Subject: Re: Representing Embedded Architectures at the Kernel Summit
Date: Tue, 2 Jun 2009 23:18:04 +0200	[thread overview]
Message-ID: <10f740e80906021418i1d58f5eer940e7a8ec9fb8b9e@mail.gmail.com> (raw)
In-Reply-To: <20090602211057.GA10800@flint.arm.linux.org.uk>

On Tue, Jun 2, 2009 at 23:10, Russell King <rmk@arm.linux.org.uk> wrote:
> On Tue, Jun 02, 2009 at 11:29:46AM -0600, Grant Likely wrote:
>> 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).
>
> Note that I have to point out that ARM will probably never be in a
> situation where you can have a one kernel image boots on everything.
> That _is_ practical today (and does happen with all PXA now) with what
> we have within a very big restriction - which is that the kernel must
> be built to support PXA and not Atmel SoCs.
>
> I really don't think combining SoC support is going to be realistic,
> device tree or not.  When we had just four machine types (RiscPC,
> EBSA110, EBSA285, Netwinder) I did look into this and came to the
> conclusion that it would be far too inefficient for there to be any
> win.
>
> The big problem we have is that the only commonality between different
> SoCs is that the CPU executes ARM instructions.  Everything else is
> entirely up to the SoC designer - eg location of memory, spacing of
> memory banks, type of interrupt controller, etc is all highly SoC
> specific.  Nothing outside of the ARM CPU itself is standardized.

That sounds very similar to m68k, which does support generic kernels
(except for Sun-3, which uses a completely different MMU)?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert.uytterhoeven@gmail.com>
To: Grant Likely <grant.likely@secretlab.ca>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	ksummit-2009-discuss@lists.linux-foundation.org,
	linux-arch@vger.kernel.org, linux-embedded@vger.kernel.org,
	Josh Boyer <jwboyer@linux.vnet.ibm.com>,
	Tim Bird <tim.bird@am.sony.com>
Subject: Re: Representing Embedded Architectures at the Kernel Summit
Date: Tue, 2 Jun 2009 23:18:04 +0200	[thread overview]
Message-ID: <10f740e80906021418i1d58f5eer940e7a8ec9fb8b9e@mail.gmail.com> (raw)
Message-ID: <20090602211804.LoivfRnNYbI2EnoitMM2gYP_mvo6OdFhZ-DTdl-Ba2I@z> (raw)
In-Reply-To: <20090602211057.GA10800@flint.arm.linux.org.uk>

On Tue, Jun 2, 2009 at 23:10, Russell King <rmk@arm.linux.org.uk> wrote:
> On Tue, Jun 02, 2009 at 11:29:46AM -0600, Grant Likely wrote:
>> 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).
>
> Note that I have to point out that ARM will probably never be in a
> situation where you can have a one kernel image boots on everything.
> That _is_ practical today (and does happen with all PXA now) with what
> we have within a very big restriction - which is that the kernel must
> be built to support PXA and not Atmel SoCs.
>
> I really don't think combining SoC support is going to be realistic,
> device tree or not.  When we had just four machine types (RiscPC,
> EBSA110, EBSA285, Netwinder) I did look into this and came to the
> conclusion that it would be far too inefficient for there to be any
> win.
>
> The big problem we have is that the only commonality between different
> SoCs is that the CPU executes ARM instructions.  Everything else is
> entirely up to the SoC designer - eg location of memory, spacing of
> memory banks, type of interrupt controller, etc is all highly SoC
> specific.  Nothing outside of the ARM CPU itself is standardized.

That sounds very similar to m68k, which does support generic kernels
(except for Sun-3, which uses a completely different MMU)?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

  parent reply	other threads:[~2009-06-02 21:18 UTC|newest]

Thread overview: 89+ 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 15:22 ` 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: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-02 21:34                 ` Robert Schwebel
2009-06-03  3:35                 ` Greg KH
2009-06-03  0:03               ` David VomLehn
2009-06-03  0:52                 ` Eric W. Biederman
2009-06-03  1:42                 ` Steven Rostedt
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:29   ` Grant Likely
2009-06-02 17:45   ` David VomLehn
2009-06-02 17:45     ` David VomLehn
2009-06-02 18:46     ` Grant Likely
2009-06-02 17:48   ` James Bottomley
2009-06-02 17:48     ` James Bottomley
2009-06-03 12:17     ` Mark Brown
2009-06-03 12:17       ` Mark Brown
2009-06-04 18:18     ` Grant Likely
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:16       ` Bill Gatliff
2009-06-04 20:15       ` Grant Likely
2009-06-04 20:15         ` Grant Likely
2009-06-02 21:18     ` Geert Uytterhoeven [this message]
2009-06-02 21:18       ` Geert Uytterhoeven
2009-06-03  7:07       ` [Ksummit-2009-discuss] " Ralf Baechle
2009-06-02 21:40     ` Robert Schwebel
2009-06-02 21:40       ` Robert Schwebel
2009-06-02 21:48       ` Russell King
2009-06-04 20:08     ` Grant Likely
2009-06-04 20:08       ` Grant Likely
     [not found]     ` <3340601010994331832@unknownmsgid>
2009-06-04 20:24       ` Grant Likely
2009-06-04 20:24         ` Grant Likely
2009-06-03  6:53   ` [Ksummit-2009-discuss] " Ralf Baechle
2009-06-03 13:04 ` Catalin Marinas
2009-06-03 14:06   ` Jean-Christophe PLAGNIOL-VILLARD
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 18:43         ` Andrew Morton
2009-06-03 19:01         ` James Bottomley
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-04  9:23             ` Mel Gorman
2009-06-03 19:08     ` Catalin Marinas
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  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 18:18         ` Jamie Lokier
2009-06-16 19:28         ` Grant Likely
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-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  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=10f740e80906021418i1d58f5eer940e7a8ec9fb8b9e@mail.gmail.com \
    --to=geert.uytterhoeven@gmail.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=grant.likely@secretlab.ca \
    --cc=ksummit-2009-discuss@lists.linux-foundation.org \
    --cc=linux-arch@vger.kernel.org \
    /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).