Re: [coreboot] Why does src/soc/intel/ exist?

[Aaron Durbin]

On Tue, May 2, 2017 at 5:24 AM, Arthur Heymans  wrote:
> Hi
>
> I am wondering why newer intel code is being pushed to src/soc/intel/*/
> instead of the traditional src/{cpu,southbridge,northbridge}/intel ?

The era of mix and match ICs is pretty much gone. Even when there are
separate chips on a board there's only a single variant which actually
works in conjunction with the parts. Similarly to the socket
abstraction that closely coupled features to physical sockets it's not
really applicable any longer. It'd be forcing one to separate out
support where things are actually closely related.
> I know that physically things are now on one chip hence the soc but the
> code itself is often very similar to older cpu/southbridge/northbridge
> code. A good example is for instance smbus:
> https://review.coreboot.org/#/c/19372/ (unify src/soc/intel smbus code)
> https://review.coreboot.org/#/c/19258/ (unify src/southbridge/intel
> smbus code)
> with code that is almost identical so it would be beneficial to have
> this code in common for all intel targets, which is somewhat hindered or
> unpractical due to this dir separation.

How is that unpractical? I think you are assuming a specific directory
layout? Regardless of where code resides it's certainly possible to
share code. I think what you've pointed out is the timeline when new
development cutover to use src/soc for all the parts as the parts
really are SoC with a close coupling of implementations. The logic
blocks inside the parts are definitely forks of one another just like
software so there is re-use at play. With your change and the other
one we'd have 2 parallel implementations that could be tested for
parity and combined. That said, one needs to be careful in the details
for determining where something can be truly common. In the smbus
stuff specifically I'm sure there has be no real modification in a
very long time, but that isn't true for all blocks.
> The same could be said about a lot of LPC code, which has parts that are
> very similar across multiple generations, like pirq routing.
>
> Another thing to note is that dir names are often poorly named like amd
> where in src/northbridge/amd memory controller code resides, while in
> src/southbridge the code for both the northbridge and the southbridge
> resides.

I think you are seeing a reflection of how closely coupled certain
support and features are. There isn't always a hard split/separation
into those directory names because one needs to deal with configuring
multiple ip blocks for a feature.
> So my question is why does the newer codebase need to be separated like
> this and what is the benefit of doing so?

The newer code is not separated. It's actually combined? Benefit is
one stop shopping for a given platform for code to reside instead of
laying down multiple directories in various places that doesn't
reflect the construction of the systems. That said, with the
introduction of the common modules the soc/intel directories will
become thinner with selecting the common modules. That reflects more
closely how hardware development is being done.

Though the soc/ directory layout isn't the only way of making the
following work, it certainly helps. For the purposes of porting a
board based off of another board of a different platform it makes the
code maintenance easier solely based on #include files. There's really
not reason to have to #include a/specific/directory/header to make
something work. If the abstractions are done correctly one can
#include genericpath/header with a conforming API. That allows code
reuse and porting to go more smoothly. If you are having to #ifdef
CONFIG to figure out the include path in the c files that makes the
source ugly and a maintenance burden. This isn't the only the example,
but a good one where there's a ton of #ifdef for include paths:
src/cpu/x86/smm/smmrelocate.S. That's also ignoring the "common"
headers which do or don't expose certain functions that are found in
specific places as well. In short, I think the
southbridge/cpu/northbridge split in how it's been done in the past
actually creates more of a burden. Again, that doesn't mean things
can't be fixed by using consistent and namespaced include paths.
> Kind regards
>
> Arthur Heymans