Re: [Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

On Thu, Oct 24, 2013 at 10:06:24AM +0200, Sascha Hauer wrote:

On Wed, Oct 23, 2013 at 12:54:35PM -0600, Jason Gunthorpe wrote:

quoted

On Wed, Oct 23, 2013 at 08:30:42PM +0200, Richard Cochran wrote:

quoted

On Wed, Oct 23, 2013 at 12:25:02PM -0600, Jason Gunthorpe wrote:

quoted

quoted

On ARM the package of 'stuff' can very reasonably include dtb. Distro
scripts can package modules+DTB+vmlinuz into something the bootloader
can understand. (The next pain point will be to standardize that)

The DTB doesn't have to be 'outside' the distro/kernel to give users a
seamless upgrade experience.

How can a distro possibly provide me a DTB?

They don't know what hardware I am using. Only I know that.

I'm not sure what you are asking? Treat DTBs like kernel drivers. If
you make hardware and you want distros to run on it, you have to
provide the DTB for that hardware to mainline+distros.

Remember, there are two ways to view DTB:
  a) It comes from the firmware and you have to live with whatever
     crap the firmware does
  b) It comes from the kernel, must match the kernel, and we don't
     have to tolerate crap in the DTB.

c) It comes from the firmware and is at least good enough to bring up a
   kernel to install a better devicetree.

That's an interesting new view. And I think that makes a lot of sense
because it matches the product cycle pretty well. Typically I wouldn't
expect an upstream kernel to be fully featured when first shipped in a
product, for all the known reasons, but it should be possible to come
up with stable bindings good enough to perhaps boot to a command-line
prompt and have some way of accessing other files (network, block
device, ...).

Then again you could argue that the bootloader should be able to update
itself (and the DTB while at it).

Thierry