Dear coreboot folks,
As some you know we at OSF are working on enabling Xeons in coreboot. We have recently uploaded Skylake-SP which goes in src/soc/intel/skylake_sp. At the same time we are working on enabling next generation SP processor. I was wondering what may be a good way to structure the code. It feels wrong to just throw code into src/soc/intel especially for systems with discrete PCH.
I'd like to hear opinions and discuss what may be a good way to structure and organize the code. Here is what we want to achieve:
* Make code modular It looks like certain things are similar to all -SP variants and it makes sense to share that code rather than copy-paste. * Allow same motherboard to host different CPU (and potentially different PCH) The practical thing here is that some server boards support two generations of CPUs that are pin-compatible. However, chip code is different. PCH may be same or different. * Did I already say eliminate/decrease copy-pasta?
Here is a structure that I came up with so far (patch stack ending with 39017)
cpu/xeon_sp/ ├─ Kconfig # baseline of config ├─ include/ # common headers ├─ common/ # true common code such as IIO stacks code, ACPI tables ├─ cpu/skylake-sp/ │ ├─ include/ # cpu/northbridge defines specific to given model │ ├─ Kconfig # whatever overrides from common we need │ └─ *.c # code that implements specific platform bits ├─ cpu/nextlake-sp/ │ ├─ include/ # same │ ├─ Kconfig # same │ └─ *.c # same
Now then, the "common" xeon_sp code may be placed in src/northbridge. We probably should add Lewisburg C62x code in src/southbridge as well. Thoughts?
Alternatively, we can place everything in soc/intel/ and put Xeon server common code in soc/intel/common/block/ or similar. This may be easiest way but fells messy.
Is there any other way with pros and cons?
thanks Andrey