All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@ti.com>
To: Stephen Warren <swarren@wwwdotorg.org>, cross-distro@lists.linaro.org
Cc: Tom Rini <tom.rini@gmail.com>,
	devicetree@vger.kernel.org,
	Grant Likely <grant.likely@secretlab.ca>,
	Rob Herring <rob.herring@calxeda.com>,
	Olof Johansson <olof@lixom.net>, Arnd Bergmann <arnd@arndb.de>,
	Ian Campbell <ian.campbell@citrix.com>,
	Mark Rutland <Mark.Rutland@arm.com>,
	Pawel Moll <pawel.moll@arm.com>
Subject: Re: [RFC] Best practices for hardware shipping device trees
Date: Wed, 14 Aug 2013 14:25:02 -0400	[thread overview]
Message-ID: <20130814182502.GC2983@bill-the-cat> (raw)
In-Reply-To: <520BB3E6.7000205@wwwdotorg.org>

On Wed, Aug 14, 2013 at 10:44:22AM -0600, Stephen Warren wrote:
> On 08/14/2013 09:13 AM, Tom Rini wrote:
> > Hey all,
> > 
> > Do we have a document yet talking about the best practices for how we
> > would like a hardware vendor to ship, store and possibly update a device
> > tree, on the hardware?  "However they like" seems likely to invite
> > problems down the line with everyone trying their own thing.  Thanks!
> 
> I don't believe there's any written guidance, no.
> 
> The initial guidance Grant gave (IIRC at the first Linaro Connect last
> year, or perhaps the ARM workshop in Prague, or perhaps also in various
> ARM kernel list threads?) was that the DTBs should be stored/accessed in
> exactly the same way as the kernel, which on many systems implies it's a
> file in /boot (although MTD partitions, ... are also possible kernel
> locations). The idea here was to explicitly make upgrading the DTB as
> easy as upgrading the kernel, and explicitly without having to upgrade
> any firmware, since that's a more dangerous process in most cases.
> 
> Now perhaps that advice was only intended to apply very early on when DT
> was really new on ARM, and has "aged out" by now? If so, I don't recall
> that every being explicitly mentioned or communicated later.
[snip out a bit more of Stephen's answer]

Yes, this notion certainly is the opposite of what was suggested on the
cross-distro list, both as part of a "what should a bootloader provide
to get commodity distros to support the board" thread and the "where
should a device tree live in the filesystem" thread.  Cc'ing them now
because this is one of those things that feels like it needs solving,
solving soon, and done in a way the least number of folks get surprised
about it.

-- 
Tom

  parent reply	other threads:[~2013-08-14 18:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-14 15:13 [RFC] Best practices for hardware shipping device trees Tom Rini
2013-08-14 16:38 ` Jason Cooper
2013-08-14 18:41   ` Tom Rini
2013-08-14 18:53     ` Jason Cooper
2013-08-14 16:44 ` Stephen Warren
2013-08-14 17:20   ` Jason Cooper
2013-08-14 18:25   ` Tom Rini [this message]
2013-08-15  0:37     ` Nicolas Pitre
2013-08-15  2:09       ` Tom Rini
2013-08-15  2:57         ` Nicolas Pitre
2013-08-15 14:53           ` Tom Rini
2013-08-15 15:30             ` Stephen Warren
2013-08-15 16:37               ` Tom Rini
2013-08-15 17:31                 ` Stephen Warren
2013-08-15 18:56                   ` Tom Rini
2013-08-15 22:34                     ` Stephen Warren
2013-08-15 15:45             ` Nicolas Pitre
2013-08-15 17:00               ` Tom Rini
2013-08-15 23:59           ` David Gibson
2013-08-16  2:51             ` Nicolas Pitre
2013-08-19  0:15               ` David Gibson
2013-08-19 18:43                 ` Nicolas Pitre
2013-08-20  6:40                   ` Alexander Graf
2013-08-20 12:02                     ` Nicolas Pitre
2013-08-20 17:02                       ` Matt Sealey
2013-08-20 17:29                         ` Nicolas Pitre
2013-08-20 15:03                     ` Tom Rini

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=20130814182502.GC2983@bill-the-cat \
    --to=trini@ti.com \
    --cc=Mark.Rutland@arm.com \
    --cc=arnd@arndb.de \
    --cc=cross-distro@lists.linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@secretlab.ca \
    --cc=ian.campbell@citrix.com \
    --cc=olof@lixom.net \
    --cc=pawel.moll@arm.com \
    --cc=rob.herring@calxeda.com \
    --cc=swarren@wwwdotorg.org \
    --cc=tom.rini@gmail.com \
    /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.