ACK: [PATCH 0/2] [SRU] [X/raspi2] Overlay files don't get applied

[Kleber Souza]

On 07/12/17 12:41, Paolo Pisati wrote:
> BugLink: https://bugs.launchpad.net/bugs/1703802
> 
> Impact:
> 
> While working on a bug that involved loading an overlay dtb files upon boot, i
> noticed that, no matter what i put in config.txt::dtoverlay=..., no overlay was
> loaded at all.
> 
> After further investigation i found that recently (~April 2017), the raspberry
> BSP changed the overlay files suffix from -overlay.dtb to .dtbo, and while the
> upstream bootloader was updated to accept the new scheme, we keep shipping an
> older bootloader in the the archive that didn't know about this change.
> 
> To make this bug more annoying, the bootloader doesn't emit an error or a
> warning if it fails to load an overlay, it silently ignores it and keep going.
> 
> Ubuntu core #stable isn't affected by this bug since it's shipping it's own
> overlay files in a static tarball (using the old scheme), and #edge (that is
> where new daily images are built) is shipping an older kernel with the old
> scheme.
> 
> While #beta and #candidates should be affected.
> 
> Fix:
> 
> A way to fix this bug would be to update the raspi2 bootloader to a more recent
> version, but since updating it has proven challenging in the past (multiple
> images from multiple sources, #updates vs #security, different boot configs,
> etc), i'm taking a more straightforward approach by reverting the dtb overlay
> files rename back to the previous scheme.
> 
> With that said, i'm concurrently opening another LP bug (1703799) because we
> must update the bootloader and revert this fix as soon as the new bootloader
> lands in the archive.
> 
> How to test:
> 
> The are different ways you can test this (like modifying the
> config.txt::dtoverlay=... parameter and then checking that the corresponding
> hardware started to work, but then you would never know if it's a kernel driver
> problem, a dtb merge problem, wrong wiring, failing hardware, etc), but the best
> way is to use the dtc to dump out the dts structure before and after the
> dtoverlay modification and then diff the two:
> 
> vanilla image:
> 
> $ dtc -I fs -O dts /proc/device-tree > pi3-vanilla.dts
> 
> now install the new kernel with the revert (dpkg -i ... or snap install ...),
> modify dtoverlay, reboot and dump again:
> 
> # echo "dtoverlay=vc4-kms-v3d" >> /boot/firmware/config.txt
> # reboot
> 
> $ dtc -I fs -O dts /proc/device-tree > pi3-vc4.dts
> 
> check if the dtb passed to the kernel has changed:
> 
> $ diff -du pi3-vanilla.dts pi3-vc4.dts
> [check that there's actually a diff and something sensible was applied]
> 
> if you are doing this on ubuntu-core, config.txt is located in
> /boot/uboot/config.txt, while if you are doing this in ubuntu classic, remember
> to manually copy the overlay files that are shipped with the new kernel:
> 
> # rm -rf /boot/firmware/overlays
> # cp /lib/firmware/`uname -r`/device-tree/overlays /boot/firmware
> 
> Paolo Pisati (2):
>   Revert "dts, kbuild: dtbs_install installs .dtbo files too"
>   UBUNTU: [SAUCE] Revert "BCM270X_DT: Add a .dtbo target, use for
>     overlays" and subsequent
> 
>  arch/arm/boot/.gitignore            |   2 +-
>  arch/arm/boot/dts/overlays/Makefile | 207 ++++++++++++++++++------------------
>  scripts/Makefile.dtbinst            |  10 +-
>  scripts/Makefile.lib                |  10 --
>  4 files changed, 110 insertions(+), 119 deletions(-)
> 

Acked-by: Kleber Sacilotto de Souza <kleber.souza at canonical.com>