[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

Mark Rutland mark.rutland at arm.com
Tue Jan 10 19:34:35 CET 2017


On Tue, Jan 10, 2017 at 05:17:07PM +0000, Ryan Harkin wrote:
> On 10 January 2017 at 16:58, Alexander Graf <agraf at suse.de> wrote:
> > On 01/10/2017 05:47 PM, Ryan Harkin wrote:

> >> I have a background task to refactor u-boot support for ARM Ltd
> >> boards. One of many options I was considering was to have a minimal
> >> DTB to configure the platform with only the nodes needed for u-boot.
> >> The ARM Ltd device trees fluctuate so much, I wouldn't be able to
> >> commit to one DTB that will work forever...
> >
> > No, it's only meant as a fallback when no manual device tree is provided.
> 
> Thanks for confirmation.
> 
> > In an ideal world however, device trees are static and complete, so
> > you could just put a final dt into U-Boot and have it propagated all
> > the way through.
> 
> I look forward to living in this ideal world the EDK2 and kernel
> communities promised me several years ago ;-)

To be fair, the *upstream* DTs for ARM Ltd platforms are relatively
stable. I must assume you're talking about random platform trees from
elsewhere, which it's not fair to blame the EDK2 or Linux communities
for. ;)

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.

It's certainly not great that those aren't in a separate canonical repo,
but in terms of stability we are largely there, random *not upstream*
platform trees notwithstanding. We'll never get complete from day one,
so some updates over time are a fact of life, but we are in the position
to ship something that continues to work...

Thanks,
Mark.


More information about the U-Boot mailing list