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: > > On Wed, Oct 23, 2013 at 08:30:42PM +0200, Richard Cochran wrote: > > > On Wed, Oct 23, 2013 at 12:25:02PM -0600, Jason Gunthorpe wrote: > > > > > > 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
Attachment:
pgpxSko5vaIEz.pgp
Description: PGP signature
