I'm having a look at this

+Marco
+Benson

Here's what I think:

At present each board (reef/pyro/snappy/...) has its own private ebuild
to install touch firmware for use by the touch-firmware updater.

With unified builds we want to have a single image which can run on all
boards. It therefore needs to hold touch firmware for all the boards, with
the correct firmware selected at run time.

The kernel's 'request firmware' hotplug interface works from a product ID
and revision. This should continue to work in the unified build context.
Therefore no changes should be needed at run time.

At build time we currently read a tarfile from GCS and install it into
/opt/google/touch. It seems like a lot of hassle to build this file when
we could just update the files in the ebuild. In fact we recently added a
650-line shell script (update_new_firmware_version.sh) to handle this.

This method makes it hard to share files since every board has its own tar
file.

Instead we can install the firmware in the files/ directory of the ebuild.
Further, we can set up a shared ebuild in the build for use by all boards
which use this baseboard.

Simon: We already have support for this in the touch updater, with support for multiple sourced trackpads, and with chassis ids.

Take a look at Reef. Reef actually supports three different trackpads, across three different hardware skus...

1. Reef prototype 
2. Electro (Acer design)
3. Basking (Asus design)

I'm not sure there's a problem to be solved here... If you wanted to fold Pyro and Snappy touch firmwares into Reef, I'd support that, but use the method that's already there.

Simon: I was under the impression that we really don't want to support hosting binary blobs in source control in overlays. That's why we use BCS for hosting blobs of firmware that are provided by third parties.

At present the firmware is in chromeos-touch-firmware-reef which is not used by pyro, for example. So how can I make that work? I think at least I need to move it to the baseboard.

Re binary blobs in BCS, this adds a lot of complexity as described above. What is the benefit? With AP/EC firmware we at least have the need to support a different version from ToT, but that's not what touch firmware does, right?

CLs here:

https://chrome-internal-review.googlesource.com/c/415970/
https://chrome-internal-review.googlesource.com/c/415971

+bernie to talk about putting the binaries in git.

Before we go checking these into a git repo, we should look into what our actual constraints are, specifically what level of privateness do we need for these binaries?

Presumably we can share them among any given partner, but can we just make these public?

Is there any reason we can not just make these firmware binaries public? We should have the rights to do so with our agreements, and the binaries ship publicly anyway in OS images, if these can be public we can just put them on the chromeos-localmirror GS bucket and then we have no access problems and we can keep our git history clean.

Follow-up from Bernie:

LGTM, they are pretty small, this is probably a good compromise to make

I'm going ahead with the CLs

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chromeos/overlays/baseboard-reef-private/+/8e3f65db8c43a079c49a309601c65af419ba00b9

commit 8e3f65db8c43a079c49a309601c65af419ba00b9
Author: Simon Glass <sjg@chromium.org>
Date: Mon Jul 24 23:54:40 2017

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chromeos/overlays/overlay-reef-private/+/ae2dafc2ca23f98324c5bf5b91e98a6640b349ad

commit ae2dafc2ca23f98324c5bf5b91e98a6640b349ad
Author: Simon Glass <sjg@chromium.org>
Date: Sat Jul 29 00:45:14 2017