From: Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: devicetree-discuss
<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
arm-TuqUDEhatI4ANWPb/1PvSmm0pvjS0E/A@public.gmane.org
Subject: Re: precedence of built-in vs. platform trees?
Date: Thu, 29 Nov 2012 06:06:40 -1000 [thread overview]
Message-ID: <50B78810.8010508@firmworks.com> (raw)
In-Reply-To: <CACxGe6uc-E2kHuQeKbJNDgEWLa_DLqDRzC4eRyKReeZTVdQVeA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/29/2012 1:46 AM, Grant Likely wrote:
> On Thu, Nov 29, 2012 at 6:39 AM, Jon Masters <jonathan-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org> wrote:
>> Hey guys,
>>
>> I apologize if I should have RTFM. If a platform provides a device tree
>> at boot time, and the kernel also has a tree appended, what behavior is
>> supposed to happen? i.e. what is the standard that is anticipated here?
>
> Hmmm, nobody has asked that before. I don't think it is really defined :-)
>
> I presume that the built-in DT will end up getting used from what I
> remember about the code.
That sounds like the right default, but it would be nice if one could
override it with a cmdline option. It's *usually* easier to change the
kernel than the platform firmware or bootloader, but there are
exceptions. In our (OLPC's) case, DT mods can be made trivially by
editing a script (and the firmware includes an editor). We use this
feature all the time in development, and sometimes even for customers,
for testing bug fixes.
>
> g.
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
prev parent reply other threads:[~2012-11-29 16:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-29 6:39 [fedora-arm] precedence of built-in vs. platform trees? Jon Masters
[not found] ` <50B7033C.3030204-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org>
2012-11-29 11:06 ` Leif Lindholm
2012-11-29 11:46 ` Grant Likely
[not found] ` <CACxGe6uc-E2kHuQeKbJNDgEWLa_DLqDRzC4eRyKReeZTVdQVeA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-11-29 16:06 ` Mitch Bradley [this message]
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=50B78810.8010508@firmworks.com \
--to=wmb-d5eqfidgl7eakbo8gow8eq@public.gmane.org \
--cc=arm-TuqUDEhatI4ANWPb/1PvSmm0pvjS0E/A@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.