From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Rutland Date: Thu, 12 Jan 2017 12:25:40 +0000 Subject: [U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob In-Reply-To: <1484074219.3144.24.camel@linaro.org> References: <2b4f0cab210294fccacd639c13cae038ca842f6b.1484053094.git.michal.simek@xilinx.com> <0da73708-605b-780f-a38d-6af34ece60fc@suse.de> <0c69ad6e-82ce-57a0-d392-e154115d0ca3@suse.de> <20170110183435.GA25493@leverpostej> <1484074219.3144.24.camel@linaro.org> Message-ID: <20170112122540.GE10615@leverpostej> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Jan 10, 2017 at 06:50:19PM +0000, Jon Medhurst (Tixy) wrote: > On Tue, 2017-01-10 at 18:34 +0000, Mark Rutland wrote: > > Looking at the git log for arch/arm64/boot/dts/arm, most updates are > > simply adding new descriptions, so a DTB from a year ago should work > > just fine with mainline (modulo the Juno PCI window issue, which was a > > DTB bug). Upgrading kernel shouldn't require a DTB upgrade to see > > equivalent functionality. > > But if you want the new functionality in the kernel, why should you be > forced to wait for the bootloader to catch up (or do that work yourself) > then upgrade to that new bootloader version??And what about the poor > devs working on that new functionality, they're going to need to use not > upstream device-trees. Then there's all the firmware and system > configuration stuff that's in device-tree. Developers working on low-level stuff will always need to be able to override/upgrade/etc. I am certainly not arguing to remove those capabilities. The key point is that it is possible to provide a baseline DTB that is good enough for most users, and will work with future kernels. We're unlikely to get to a state where DTBs are perfect and complete from day one. We can have something that remains usable. Thanks, Mark.