Xeon SP code structure

[Andrey Petrov]

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