> 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
we often intentionally only add a few boards for every generation
(keeping the others in the respective release firmware branches like
). 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
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.
5) 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).