In the main Chromium OS Board Porting Guide, we covered how to create a new board overlay for a project. The goal there was to create a board that'd be published for anyone to build themselves. However, it is not uncommon for people to want to develop their boards in secret before launch, or to have a few pieces that never get publicly released. Chromium OS provides a framework for that too, and this guide covers that.
Note that this guide is not standalone. You should be familiar with the aforementioned board porting guide as we will not duplicate topics that are in common.
Some examples of things that won't be released (whether it be practical or political or legal):
Private and public overlays do not work in isolation. This means that if you have both private and public board overlays, they will both be used. This allows you to have a public overlay that includes as many releasable pieces as possible (and produce a usable image) while having a private overlay with just the few additional private-only pieces.
Often times people will start by creating only a private board overlay (which is a perfectly valid setup), and then once things have been released, create a public board overlay. This is the recommended workflow and you should keep this in mind when writing the private overlay -- don't make things harder for the public release. The goal of this guide is to show how to create a private overlay that is geared towards being released later on.
While public overlays live in src/overlays/overlay-$BOARD/, private overlays live in src/private-overlays/overlay-$BOARD-private/. The file structure is the same though.
Even if you have a public overlay, you will need at least these files (even if there is no content in them like make.conf):
Most of these files are one or two lines. Let's go through them one at a time.
Since this will be a super set of the public overlay's make.conf, use this form:
The thing to make note of is that we only incrementally set variables here (notice how the first thing we do in USE is set it to $USE). Keep that in mind with any variable you use here -- you most likely want to include the previous value as that is coming from the public overlay. Only clobber when you specifically know you want to.
This will be the same as the public overlay, except you'll want to add a "-private" suffix to the "repo-name" field. Here's what the private overlay for the lumpy board uses:
If you have a public overlay already, then the preference would be to redirect to that. Here is how the private lumpy overlay does it:
You can still add private specific settings to the profile by adding files under profiles/base/.
If you don't have a public overlay, then this will have the same content as if you had a public overlay (see the public porting guide for more info).
For now, this should be the same as the public overlay. We plan on making this incremental too, but haven't yet done so.
Even though your board is private, you'll still need to update this central (public) location. It keeps us from stepping on each others toes.
Just like the public overlays are allowed to have board variants, so can private boards. As you'd expect, the paths look like: