Ok thanks for clarifying. Aaron Durbin <[email protected]> writes:
> On Tue, May 2, 2017 at 5:24 AM, Arthur Heymans <[email protected]> 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: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
