Some arm64 devices (like espressobin) boot using u-boot and not using
efi. For these the kernel's corresponding dtb is required to boot.

I only checked the latest daily netboot.tar.gz, and while armhf ships
those files, arm64 does not.

When fishing out the dtb out of the binary kernel package and using that
for netboot, the installer works just fine - including its flash-kernel
run, which makes the freshly installed system bootable using dtb.

Please don't ship dtb files at all, including the kernel images.

If firmware does not come with hardware description, that is a
shortcoming of the firmware. If a newer kernel cannot be booted with
an existing device tree, then that is a bug and the kernel should be
patched.

By all means, put a tree of verified actually working device trees
somewhere for platforms known to be provided with bad versions from
their manufacturer.

Andre Heider <a.heider@gmail.com> wrote:

Hello,

it appears to me that this argument assumes a situation that we
simply don't have for many devices.  A lot of the ARM-based
devices that Debian supports don't come with any preinstalled
firmware at all.  Many of them don't even have permanent onboard
storage (such as an SPI NOR flash) in which such a firmware could
be stored, so the firmware is commonly a user-supplied u-boot
image on an SD card.

In practice, for most of the devices supported by Debian/armhf,
the canonical source for the devicetree _is_ the Linux kernel.
The SoC-manufacturers commonly ship years-old, often
pre-devicetree android kernels and stone-aged hacked-up u-boot
versions without any notion of device-tree for their hardware and
don't really care about mainline Linux.  AIUI, the situation for
arm64-based SBCs appears to be roughly similar - server-class
arm64 hardware is another topic, but Debian doesn't only cater
for server-class hardware but also for a broad base of cheap SBCs
based on SoCs built for the android market.  In some cases the
manufacturer ships a hacked-up 3.10-based android kernel that
even has a device-tree, but the bindings used in there are
partially "homemade" and incompatible with the mainline bindings,
i.e. the device-tree provided by the manufacturer is effectively
unusable with mainline kernels.

For systems supported by mainline u-boot we are slowly getting to
a situation where more and more devices are converted to the
"new" u-boot device-model and use device-tree internally, and
u-boot can provide the u-boot-internal device-tree to the kernel,
but even for many of those the situation is that the support in
the mainline kernel as well as in u-boot is reverse-engineered
and new features get added to the device-tree with every kernel
release as the reverse-engineering efforts go on.

I understand your argument and from the view of server-class
systems it makes sense, but in the field of SBCs that would only
work if we had a proper, fully-featured, standards-compliant
device-tree from the manufacturer right from the start for every
device, which is a situation that we unfortunately don't have
and probably won't have for the forseeable future.

The common case for SBCs is that there is _no_ working
device-tree from the manufacturer.

Regards,
Karsten

Ok, so in your world a distribution should not ship any dtb files,
because the manufacturer's firmware is bug-free and feature complete on
day one.

That's nice, but doesn't sound like the real world at all.

 > By all means, put a tree of verified actually working device trees
 > somewhere for platforms known to be provided with bad versions from
 > their manufacturer.

That tree is the sum of the dtb files of the corresponding kernel, which
this bug report is about. Those may not adhere to your definition of
verified, but please don't forget that there're two separate worlds out
there: upstream and downstream. Debian's current way of booting a kernel
release with its dtb ensures those world never collide, and I think that
is a very wise choice.

I don't know what devices you work on, but I have a couple of different
consumer armhf and arm64 devices, spread out over different
architectures. All their device trees are updated every single kernel
release. Often it's for new drivers like mmc, pci, net, dri etc., which
obviously the installer could make use of. Bindings are merged with the
driver, so of course I want the dtb matching its kernel!

Hello All,
...
+1

And additionally fiddling with devicetree should be encouraged IMHO as
it allows to do unusual things with those SoC boards, eg. sharing
an IR RX with an UART TX - how should the vendor decide in such cases ?

Also look at the ACPI situation - even main Server vendors firmware
contains bugs not fixed during the livetime of the systems.

So please let the linux kernel tree be the device-tree reference.
Thanks for all the work on device-tree,
 greetings
  Hermann

Note also that at least some ARM subarch maintainers explicitly require
that the DTB should be kept in sync with the kernel, i.e. that newer
kernels may not necessarily work with older dtbs (that is kernel
supplied ones, quite apart from what the manufacturer may have
provided):

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/373922.html

Ian.