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

[Arthur Heymans]

Ok thanks for clarifying.

Aaron Durbin <adurbin at google.com> writes:

> On Tue, May 2, 2017 at 5:24 AM, Arthur Heymans <arthur at aheymans.xyz> 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.
>
Ok that explains a lot. Southbridges could often occur with 2-3
different memory controllers and a similar amount of different CPU.

>>
>> 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.
>

My main thought was that is a bit sad that efforts to make more code
common happens in src/soc/intel/ while there is a lot in
src/southbridge/intel that can be set up with identical code (but maybe
smbus is indeed the only thing that can cleanly be common without too
much per platform guarding). 

>
> 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.
>

Ok thanks for the insight. Some things that were used by different
IC combinations were indeed a mess with amd in particular (but that is
probably because a lot of code was not linked)


-- 
Arthur Heymans