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

Marc Jones marcj303 at gmail.com
Tue May 2 18:49:34 CEST 2017


On Tue, May 2, 2017 at 10:30 AM Arthur Heymans <arthur at aheymans.xyz> wrote:

> 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)
>
>
>
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 at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
http://marcjonesconsulting.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170502/9cf3271d/attachment.html>


More information about the coreboot mailing list