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

[Marc Jones]

On Tue, May 2, 2017 at 10:30 AM Arthur Heymans  wrote:

> Ok thanks for clarifying.
>
> Aaron Durbin  writes:
>
> > 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.
> >
> 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)
>
>
>
We are starting to look at this structure for amd. There really isn't a
hard line between the device internally no and find a lot of dependency on
each of the silicon directories. The soc/ is a much better representation
of the devices and the setup. Getting the right level of common code is the
trick.

Marc





> --
> Arthur Heymans
>
> --
> coreboot mailing list: coreboot@coreboot.org
> 

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

[Arthur Heymans]

Ok thanks for clarifying.

Aaron Durbin  writes:

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

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Aaron Durbin via coreboot]

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
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Arthur Heymans]

Hi

I am wondering why newer intel code is being pushed to src/soc/intel/*/
instead of the traditional src/{cpu,southbridge,northbridge}/intel ?

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.

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.

So my question is why does the newer codebase need to be separated like
this and what is the benefit of doing so?

Kind regards


Arthur Heymans


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot