To my knowledge, upstreaming boards during the Haswell days wasn't a priority, and was often done by non-Google devs (like me) who happened to have a particular device. Within the last ~6 mos this has changed significantly, and there's been a large push to keep the two in sync.
I don't know if we have an official policy regarding upstreaming on this, but in our own master at https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/master we often intentionally only add a few boards for every generation (keeping the others in the respective release firmware branches like https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware... ). The reason for that is simply to reduce clutter, since we often have a lot of different boards using the same chipset and very similar board layouts, which essentially just gives us dozens of directories with 99% copied code (e.g. see all the veyron_* boards in https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware... for some of the worst offenders, which are 100% identical except for different board ID numbers).
We've been talking in the past about ways to more effectively share code between boards but didn't really have time to tackle it yet. Until then, I don't expect we'll upstream any more boards than we're keeping in our own master (which is sometimes a quite arbitrary distinction based on how early we started working on that board). The best way to build upstream firmware for one of those derivative boards (like Wolf) is probably to find the corresponding "lead" board (in this case Falco), diff the respective two boards in the Chromium firmware branch(es), and apply that (hopefully very small) diff to the current upstream version of that lead board.
- Despite attempting to set the boot menu key to ESC rather than F12 (and verifying the boot-menu-key and boot menu-message appeared with csfbtool), it still came up with F12 when I booted. Fortunately I have a USB keyboard handy, and was still able to boot a Lubuntu install.
Did you use SeaBIOS directly as a payload, or did you build an image the Chromium way (with the "depthcharge" payload that chainloads SeaBIOS when you press CTRL+L)? In the latter case SeaBIOS is wrapped into its own little CBFS in a different FMAP section, and you cannot directly access it with cbfstool without extracting it first (you would instead write your files to the main coreboot CBFS where nothing is reading them from).
-
Julius Werner