the trouble is that the linux-kernel ebuild does install a lot of firmware files:
$ qlist-amd64-generic sys-kernel/chromeos-kernel-4_4 | grep /lib/firmware | wc -l
113

granted it's rare for people to update the firmware in their kernels when doing work, but it is possible.

i've pushed for stopping that so all firmware comes from other packages (namely, linux-firmware), but i haven't been posting CLs, so it's been slow going ;).

i think the fix is to have update_kernel query for the firmware files installed by the active kernel and then only update those.

I can't say I've had this be a problem for me very often (or ever) in the past six years -- is it happening because the kernel you're building is overwriting a firmware that came from linux-firmware?

#1: Thanks vapier for correcting me, looks like we need a smarter solution...

Also, I had no idea that this feature was actually useful to anyone ,-)

#2: This just hit Daniel and I at a few months interval due to mismatching Imagination PowerVR firmware (that comes from img-ddk[-bin] ebuild), and we both wasted considerable time on that, wondering why the board was not booting to UI, as we just upgraded img-ddk from 1.6 to 1.7, and the old firmware does not work with new kernel driver (and vice-versa). We also had issues in the past with Mediatek VPU firmware, for similar reasons.

I spent a bit of time looking at this.  ...and it's my opinion that we should go back to v2 of http://crosreview.com/439046 and just land it.  

Here's why:

> granted it's rare for people to update the firmware in their kernels 
> when doing work, but it is possible.

IMHO this is not an important workflow.  Looking at history, this is the changes we've made to the kernel firmware directory:

$ for v in *; do echo $v; cd $v; git log --oneline linux/master.. firmware; cd ..; done

v3.10
f8f054abc0cf Revert "Add radeon firmware to x86-generic kernels."
151a8b0c284e Revert "CHROMIUM: firmware: import amd fusion gpu firmware"
82289df37169 Revert "CHROMIUM: Firmware: Add AMD fusion firmware."
025547b20c75 CHROMIUM: firmware: do not install radeon firmware
814f066ea2da Add radeon firmware to x86-generic kernels.
af8e083323c8 CHROMIUM: Firmware: Add AMD fusion firmware.
a11632c3019c CHROMIUM: firmware: import amd fusion gpu firmware

v3.14
2f3538b5c89d CHROMIUM: firmware: do not install radeon firmware

v3.18
aa87ad7ad7d8 CHROMIUM: firmware: do not install radeon firmware

v3.8
2319b68ebc76 CHROMIUM: bluetooth: add ath3k firmware
dcc26d2e852a Add radeon firmware to x86-generic kernels.
cbe05a5b0165 CHROMIUM: Firmware: Add AMD fusion firmware.
4e89ae4005fc CHROMIUM: firmware: import amd fusion gpu firmware

v4.12
fatal: ambiguous argument 'linux/master..': unknown revision or path not in the working tree.

v4.4
0c4e333d1895 CHROMIUM: firmware: do not install radeon firmware


That's the sum total of changes in the last 5 years.  ...and many of those changes have since been reverted.  People don't really change the firmware in the kernel directory.  As discussed in  bug #770230  we should be moving away from linux-firmware anyway.

---

> i think the fix is to have update_kernel query for the firmware files
> installed by the active kernel and then only update those.

Is there a way to do this that's _fast_?

I don't want an equery running at update_kernel time.  update_kernel needs to be as speedy as possible and I think equery to figure everything out might be a little too slow, right?  Basically to be totally correct, I think you'd need to do an "equery belongs /lib/firmware" to find out which kernel was actually the one that installed things in "/lib/firmware".  Then you'd need to do an "equery files <kernel ebuild>" to get a list of the files.  The belongs is too slow.

You could do something simpler and just try to figure out which kernel is normally installed by the given build, but that's not guaranteed to be correct.  I have, at times, unmerged the normal kernel version, emerged a different one, then used update_kernel.

Plausibly we could use cros-kernel2.eclass to create a file somewhere that listed the firmware files installed by the kernel and that would probably be fast (we don't want to slow down kernel builds either).  If that's OK then we could probably do that...

---

In any case we are slowly moving away from the kernel installing firmware anyway as per  bug #770230 .  It seems like just changing the default would be a simple path forward.  Send out a PSA to chromium-os-dev and the kernel team list and IMHO  that would be OK.

Something like this could be used:

kernel=$(equery-$BOARD l -f -F '$cpv' "sys-kernel/*" | {
  while read package; do
    if equery-$BOARD f $package | grep -q '^/boot/vmlinu[xz]'; then
      echo $package
      break
    fi
  done
})

equery-$BOARD f $kernel | grep '^/lib/firmware'

That runs in 3 seconds which isn't _too_ bad...

But, yes, in light of the analysis in #4, I'd rather go with http://crosreview.com/439046 and send a PSA, that's just so much simpler, less hacky, more consistent with what we want in the long term anyway (no firmwares in kernel packages).

I'm going to say "no" to adding 3 seconds to update kernel.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/crosutils/+/a595deb61b1b1805837f8b9dbbc832b8cda7d8c1

commit a595deb61b1b1805837f8b9dbbc832b8cda7d8c1
Author: Nicolas Boichat <drinkcat@google.com>
Date: Tue Oct 03 03:25:41 2017

update_kernel.sh: Do not copy firmwares to DUT, by default.

By default, running, in ~/trunk/src/scripts:
./update_kernel.sh DUT_IP

will upload to the DUT:
 1. kernel
 2. modules (/lib/modules/vX.Y.Z)
 3. firmware (/lib/firmware)

1+2 are necessary to get the kernel booting, but uploading firmwares
can lead to unintended breakage, as the firmwares are usually built
using other ebuilds (e.g graphics drivers, linux-firmware, etc),
leading to all sort of possible mismatches (outdated developer build
environment, accidental updating to too-recent firmware on old kernel).

BUG= chromium:689448 
TEST=./update_kernel.sh DUT_IP does not upload firmware
TEST=./update_kernel.sh --firmware DUT_IP does upload firmware

Change-Id: Iff7ad52f9da0bf04375d9e2d9cbee0b4c03415d7
Reviewed-on: https://chromium-review.googlesource.com/439046
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>

[modify] https://crrev.com/a595deb61b1b1805837f8b9dbbc832b8cda7d8c1/update_kernel.sh

PSA sent: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-dev/-g4Z2kqIAGI