[coreboot] naming conventions and new products

Marc Jones marcj303 at gmail.com
Fri May 30 19:37:48 CEST 2014

Hi Sean,

You make a good point, but recognize that these are not easy to solve.
It is difficult to tell what version of any silicon or mainboard are
supported in coreboot as part of the organic growth and support in
coreboot. Unfortunately, I don't think that is something we can fix
with a directory, which seems to be your main complaint. The support
is constantly changing as focus is directed in particular areas based
on need and interest of the participants. It is difficult to support
so many different architectures and silicon in a single tree. It is
something that is always being discussed and improved.

On Fri, May 30, 2014 at 1:14 AM, Sean McNeil <seanmcneil3 at gmail.com> wrote:
> I was wondering what is the process for creating new products and what to
> call them. In short, who comes up with these names?
> For instance, there are a few Intel CPUs called Baytrail - Celerons for
> Desktops and Tablets, Atoms for Embedded. They are both represented now in
> the coreboot source tree. The Celeron Baytrail-T seems to have been provided
> by Google for their Rambi Chromebook. The sources have gone in
> src/soc/intel/baytrail.

The support in that directory is for MRC/SystemAgent/ChromeOS
solution. It support D, M, but I'm not sure about T. Maybe the most
recent binary release supports T. The MRC/SytemAgent binary could
support Baytrail-I in the future.

> OK, that seems fair. But it isn't for the Baytrail-I processor (from the ISG
> division of Intel). Just recently Sage has committed code for Baytrail-I as
> src/soc/intel/fsp_baytrail. I find this very unwieldy and lacking clarity in
> naming conventions.

The FSP currently released by Intl only support Baytrail-I, but that
could be expanded in the future. The naming convention indicates how
the device is supported, via the FSP. We don't expect that the
coreboot FSP code for other Baytrail devices would ahve any
significant changes.

> 1) In no way is it clear from the names that src/soc/intel/baytrail is for
> "D,M,T" versions of the CPU.

Agree, but we will always have this issue as new slilicon versions
that are added and supported by coreboot. Especially when the coreboot
code wouldn't need to change to support them, just the MRC.bin.

> 2) In no way is it clear from the names that src/soc/intel/fsp_baytrail is
> for "I" versions.

We tried to be helpful with the commit message and with the kconfig
help option, but the directory is for FSP based support. We have not
limited the version supported in coreboot.

> 3) Why in the world is fsp_ added to the name like that? FSP support should
> be somewhat generic in nature and IMHO doesn't need to be spelled out like
> that.

The FSP support in coreboot is meant to be generic in nature. The
support is limited by the FSP, not by coreboot's support of the FSP.

> 4) There is a lot of copied code from src/soc/intel/baytrail to
> src/soc/intel/fsp_baytrail. Some integration would by nice.

We also agree and are looking to integrate them in the future. We have
decided to push the duplication before the integration for two

1. Integration take a lot of work and testing, so we need to
coordinate that in the community.
2. For the community, moving the code to be integrated prior to seeing
what is being integrated causes a lot of extra work and second
guessing as to the need and intent. Now, everyone can see what is
common and what isn't and have an intelligent conversation about how
we want to integrate instead of guess about what is needed and what
can be shared.

> It would be great if some person or committee were to help clarify and make
> naming conventions a little easier to understand.

A committee has never helped clarify anything ;). If you would like to
propose a solution, we would love to hear it.

> By the way, I have a fully functional version working on Baytrail-I as well
> and I put it in my tree as src/soc/intel/baytrail-isg. Works great for
> Bakersport and BayleyBay CRBs. It was my intention to contribute this at
> some point, but I doubt now it will get accepted even if better and more
> complete.

Great, we look forward to your contributions and bug fixes.


> Cheers,
> Sean
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot


More information about the coreboot mailing list