+vapier

We might make the same argument for chipset overlays, if there will never be any other consumers of this chipset. 

I am hesitant to do this because this means inconsistency between modern overlays, though I agree it would be logical for Grunt. If we do this we should make it the standard behavior for any new platforms, however I suspect we may have platforms with multiple unified builds underneath so this may still have value.

Even if we have multiple overlays they would still be based on grunt.

Prior to unibuild we had things like sand, snapopy, pyro all needing use a common baseboard (reef). We needed a way to share ebuilds.

With unibuild there is only reef, so the baseboard becomes redundant.

I also thing it is confusing to have both a grunt overlay and a baseboard-grunt overlay. What are people supposed to use the baseboard for?

So if we made a new board, say 'grumble' that was based on the grunt design, you would have it inherit the buildable grunt overlay in place of baseboard-grunt?

It is kind of possible to do this, but not really recommended, we don't support inheriting buildable overlays for production (though we do this sort of thing for cases like grunt-ndktranslation, where it is a temporary 'scaffolding' build). Inheriting buildable overlays puts in more opportunity for ambiguity problems.


The intent of the overlay structure is described in https://docs.google.com/document/d/1F21_Mwx3dEDXlvvF63nObCyBgGnOolzMzApdjf9yMkY/edit though I agree much of baseboard can be moved about into either chipset or board overlays.

In general if we never have more than one build per baseboard then I agree with your analysis, however if we are likely to have multiple, I would like to keep the overlay structures consistent, while the use of the baseboard may be confusing, having some with baseboards and some without seems worse to me.

baseboard is meant to contain all the board hardware w/out a software stack.  overlay-grunt is meant to bring the board hardware with a software stack (e.g. CrOS).

we've def used this model in the past with projects that are bootstrapping themselves (e.g. jetstream, but that's not the only one), and we should be using this for projects that re-use the hardware (e.g. moblab).  since overlay-grunt is "i'm running CrOS on grunt like a Chromebook", having projects inherit/extend overlay-grunt is wrong and doomed to failure (as we've seen actively in the past).

Re #3, I don't think we do that in a unibuild world. We just add a new model. As soon as we decide to add a new board, we are not using unibuild anymore :-)

Re the doc, I think we should consider updating it for unibuild.

I agree re consistency, to a point. The problem is that we have baseboards for many things now and are adding empty baseboards for unibuild builds, just to keep it consistent. IMO as soon as someone actually uses the baseboard for a unibuild, we have lost, and unibuild is no longer.


Re #4:

Yes we should not extend Grunt. That's basically my point.

you've lost me.  just because we're using unibuild doesn't mean the baseboard concept is gone.  if someone wanted to take grunt and run moblab or jetstream or something else on it, the whole point of baseboard-grunt is to make that easy to do.

if all the board-specific (and software stack independent) settings are being stuffed into overlay-grunt, then that's a mistake.

OK, so what packages should we have in the baseboard for unibuild, and what should be in grunt? At the moment we have almost everything in grunt.

i'm not familiar with grunt, so i don't know the answer to that.  i think the design doc already lays out the guidelines:

> Board pieces (hardware tuning, firmware, bootloader, etc…); generally for reference boards (e.g. beltino, daisy, rambi, slippy), but can be used also for non-reference boards (e.g. panther which then is used by moblab/jetstream/etc…).
> Note: Not the same as overlay-$BOARD as that will contain OEM customizations for a specific OS

i guess it's good i'm consistent in my thinking as i only just now opened the design doc, and that section matches the comments i wrote above ;)

so if you were to take a grunt board right now and run moblab/jetstream/whatever on it, what packages would it need ?

I don't have any experience with jetstream etc.? My guess it is that it would need all the ebuilds so far as I can see it.

Things like touchpad firmware would presumably not be needed. But in a unibuild world that is removed by adjusting the config, not removing ebuilds.

But things like jetstream and moblab are outside the scope of unified builds, they contain substantially different binaries, and are for very different use cases, they are not really 'Chrome OS' in the traditional sense, though they consume the basic functionality of the platform.

It is quite possible that Grunt will never be used in this capacity, but in the name of consistency we probably want to keep the capability available, given the baseboard already exists, removing it does not seem to buy much.

For some more examples where this might apply see https://docs.google.com/presentation/d/1VvTv3wSzo_9CI8dqRFcbY7UXyncWab1zS6X3EJBBsn8/edit#slide=id.g38f0b9c46f_0_0

you don't have to be familiar with jetstream specifically to go through the exercise of imaging a device using the gru hardware but isn't running CrOS like a Chromebook.  jetstream is simply a WiFi router.

if the firmware is specific to the board and would be the same regardless of the final software running on top of it, then it sounds like baseboard would be appropriate.  it might be that the overlay-grunt is a bit thin.

metadata/layout.conf and profiles/ are the biggest differentiaters as they select the other software stacks & USE customizations.

This bug has an owner, thus, it's been triaged. Changing status to "assigned".

Sorry, was out for a few weeks..

To summarise, it sounds like the baseboard is not just a way of sharing code without unibuild, but also a way to ship different products based on the same board design. In this case we might have a different set of packages to build, not just a different configuration.

I don't believe this will happen with Grunt, but for consistency it sounds like we should keep the baseboard around.

Perhaps the answer here is to update go/scalableoverlays (or better, some page on chromium.org) to mention unibuild and what baseboards are for in that context?

yep, that all sounds good.  i'll note that design doc accepts comments/suggestions from anyone :).

Added some changes here:

https://docs.google.com/document/d/1F21_Mwx3dEDXlvvF63nObCyBgGnOolzMzApdjf9yMkY/edit#bookmark=id.2kgprga42o72

I accepted the changes...making this fixed