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.
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.
1) In no way is it clear from the names that src/soc/intel/baytrail is for "D,M,T" versions of the CPU. 2) In no way is it clear from the names that src/soc/intel/fsp_baytrail is for "I" versions. 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. 4) There is a lot of copied code from src/soc/intel/baytrail to src/soc/intel/fsp_baytrail. Some integration would by nice.
It would be great if some person or committee were to help clarify and make naming conventions a little easier to understand.
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.
Cheers, Sean
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@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.
- 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.
- 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.
- 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.
- 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 reasons.
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.
Regards, Marc
Cheers, Sean
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot