On Tue, May 2, 2017 at 10:30 AM Arthur Heymans <[email protected]> wrote:
> 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) > > > 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: [email protected] > https://mail.coreboot.org/mailman/listinfo/coreboot > -- http://marcjonesconsulting.com
-- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
