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
next prev 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).