linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: david@gibson.dropbear.id.au (David Gibson)
To: linux-arm-kernel@lists.infradead.org
Subject: Boot interface for device trees on ARM
Date: Wed, 19 May 2010 10:28:26 +1000	[thread overview]
Message-ID: <20100519002826.GG25892@yookeroo> (raw)
In-Reply-To: <alpine.LFD.2.00.1005180802010.12758@xanadu.home>

On Tue, May 18, 2010 at 08:24:06AM -0400, Nicolas Pitre wrote:
> On Tue, 18 May 2010, David Gibson wrote:
> > On Tue, May 18, 2010 at 01:24:43PM +0800, Jeremy Kerr wrote:
> > > Nicolas Pitre wrote:
[snip]
> > The only reason you'd need a subarchitecture number or equivalent is
> > if you need to do things differently in the very, very early asm boot
> > code.  We may need a minimal form of this on PowerPC if we ever
> > support multiple MMU families in the same kernel binary.
> 
> Exact.  For example, on ARM the machine ID is also used to figure out 
> the MMU mapping needed to be able to simply be able to debug the very 
> early assembly boot stage when there isn't even a stack available. While 
> this info is stored in the machine record, it is actually 
> subarchitecture specific and already half-digested for easy usage by 
> that initial MMU setup.  I just don't want to imagine what the 
> equivalent functionality with DT would look like.

Well, it wouldn't be *that* bad - you'd need a minimal asm-only tree
walker to find and look up the compatible property.  Quite possible
but, yes, fairly awkward.

Yeah, if you have to make really early MMU decisions based on
subarchitecture it probbaly makes sense to have a simple ID for
those.  So one thing to consider here is that we've contemplated
adding an "MMU family" ID to the device tree blob header for this
purpose on PowerPC.  If we did such a thing, it could also be used on
ARM for a similar purpose.  Then all the relevant machine information
is in one block, and it's just a simple fixed dereference to extract
the MMU type from the early asm.

I'd have to talk to Ben et al, but I think we'd be happy enough to
create a new dtb v18 which included that field, as well as a couple of
other small improvements to the header and blob internals.  ARM could
standardize on that as the minimum acceptable dtb version.

> > > Therefore, I don't think we need the machine ID at all: once the DT is 
> > > available, we can use that for any machine-specific stuff. Even though we're 
> > > not *configuring* it from the device tree, we can *select* it from there 
> > > instead.
> > 
> > Yes, absolutely.
> 
> Please see above why I disagree.

Well, I see your point for the early MMU stuff.  However, I'm betting
there's other, later platform related setup which could just as easily
be selected bsaed on the device tree, rather than on a magic ID.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

  parent reply	other threads:[~2010-05-19  0:28 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-18  2:54 Boot interface for device trees on ARM Jeremy Kerr
2010-05-18  4:34 ` Nicolas Pitre
2010-05-18  5:24   ` Jeremy Kerr
2010-05-18  8:49     ` David Gibson
2010-05-18 12:24       ` Nicolas Pitre
2010-05-18 14:06         ` Jason McMullan
2010-05-19  0:21           ` David Gibson
2010-05-19  0:28         ` David Gibson [this message]
2010-05-19  1:28           ` Nicolas Pitre
2010-05-19  6:50             ` David Gibson
2010-05-19 14:45               ` Grant Likely
2010-05-19  1:41           ` Jamie Lokier
2010-05-19  7:12             ` David Gibson
2010-05-19 14:21             ` Grant Likely
2010-05-19  7:25         ` Mitch Bradley
2010-05-19  8:50         ` Jeremy Kerr
2010-05-18 11:57     ` Nicolas Pitre
2010-05-19 12:13       ` Grant Likely
2010-05-19 16:45         ` Jamie Lokier
2010-05-19 17:10           ` Grant Likely
2010-05-19 17:32             ` M. Warner Losh
2010-05-19 11:57   ` Grant Likely
2010-05-19 12:08     ` Russell King - ARM Linux
2010-05-19 17:52     ` Nicolas Pitre
2010-05-19 20:08       ` Jamie Lokier
2010-05-19 20:22         ` Nicolas Pitre
2010-05-21 16:24           ` John Rigby
2010-05-21 16:27             ` Jamie Bennett
2010-05-21 19:59             ` Russell King - ARM Linux
2010-06-03 21:12             ` Grant Likely
2010-06-04 20:01       ` Grant Likely
2010-06-04 20:33         ` John Rigby
2010-06-04 20:37           ` Jon Loeliger
2010-06-04 21:07             ` Grant Likely
2010-06-05  1:33         ` Jeremy Kerr
2010-06-05  2:29           ` Nicolas Pitre
2010-06-05  5:59             ` Grant Likely
2010-06-09  4:26             ` Jeremy Kerr
2010-06-09 13:09               ` Nicolas Pitre
2010-05-19 11:45 ` Grant Likely

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=20100519002826.GG25892@yookeroo \
    --to=david@gibson.dropbear.id.au \
    --cc=linux-arm-kernel@lists.infradead.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).