Ok thanks for clarifying.
Aaron Durbin adurbin@google.com writes:
On Tue, May 2, 2017 at 5:24 AM, Arthur Heymans arthur@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)
On Tue, May 2, 2017 at 10:30 AM Arthur Heymans arthur@aheymans.xyz wrote:
Ok thanks for clarifying.
Aaron Durbin adurbin@google.com writes:
On Tue, May 2, 2017 at 5:24 AM, Arthur Heymans arthur@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@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
-
Arthur Heymans -
Marc Jones