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
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
