From: jeremy.kerr@canonical.com (Jeremy Kerr)
To: linux-arm-kernel@lists.infradead.org
Subject: Boot interface for device trees on ARM
Date: Tue, 18 May 2010 13:24:43 +0800 [thread overview]
Message-ID: <201005181324.45701.jeremy.kerr@canonical.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1005172341200.12758@xanadu.home>
Hi Nicolas,
> I think that, for the moment, it is best if the bootloader on already
> existing subarchitectures where DT is introduced still preserve the
> already existing ability to boot using ATAGs. This allows for the
> testing and validation of the DT concept against the legacy ATAG method
> more easily.
Just to clarify - by "still preserve the existing ability to use ATAGs" you
mean only for non-DT boot, right? This proposal still does not require
ATAG_DEVTREE?
> Why one DT machine ID per subarchitecture? Simply because a significant
> part of the DT handling code will have to be subarchitecture specific
> anyway. The timer hardware, the GPIO configuration and muxing, SOC
> specific platform data handling, power management config, and many other
> things are simply too different from one SOC family to another and
> trying to have a single global DT support code to rule them all is
> insane.
The code for DT boot will be still subarch-specific, but I don't think we need
IDs for that. There is enough information in the device tree to select the
subarch-specific code to use for early init, without needing to parameterise
every element of the machine. The machine-level "compatible" property allows
us to do this.
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.
Cheers,
Jeremy
next prev parent reply other threads:[~2010-05-18 5:24 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 [this message]
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
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=201005181324.45701.jeremy.kerr@canonical.com \
--to=jeremy.kerr@canonical.com \
--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).