<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, May 2, 2017 at 10:30 AM Arthur Heymans <<a href="mailto:arthur@aheymans.xyz">arthur@aheymans.xyz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok thanks for clarifying.<br>
<br>
Aaron Durbin <<a href="mailto:adurbin@google.com" target="_blank">adurbin@google.com</a>> writes:<br>
<br>
> On Tue, May 2, 2017 at 5:24 AM, Arthur Heymans <<a href="mailto:arthur@aheymans.xyz" target="_blank">arthur@aheymans.xyz</a>> wrote:<br>
>> Hi<br>
>><br>
>> I am wondering why newer intel code is being pushed to src/soc/intel/*/<br>
>> instead of the traditional src/{cpu,southbridge,northbridge}/intel ?<br>
><br>
> The era of mix and match ICs is pretty much gone. Even when there are<br>
> separate chips on a board there's only a single variant which actually<br>
> works in conjunction with the parts. Similarly to the socket<br>
> abstraction that closely coupled features to physical sockets it's not<br>
> really applicable any longer. It'd be forcing one to separate out<br>
> support where things are actually closely related.<br>
><br>
Ok that explains a lot. Southbridges could often occur with 2-3<br>
different memory controllers and a similar amount of different CPU.<br>
<br>
>><br>
>> I know that physically things are now on one chip hence the soc but the<br>
>> code itself is often very similar to older cpu/southbridge/northbridge<br>
>> code. A good example is for instance smbus:<br>
>> <a href="https://review.coreboot.org/#/c/19372/" rel="noreferrer" target="_blank">https://review.coreboot.org/#/c/19372/</a> (unify src/soc/intel smbus code)<br>
>> <a href="https://review.coreboot.org/#/c/19258/" rel="noreferrer" target="_blank">https://review.coreboot.org/#/c/19258/</a> (unify src/southbridge/intel<br>
>> smbus code)<br>
>> with code that is almost identical so it would be beneficial to have<br>
>> this code in common for all intel targets, which is somewhat hindered or<br>
>> unpractical due to this dir separation.<br>
><br>
> How is that unpractical? I think you are assuming a specific directory<br>
> layout? Regardless of where code resides it's certainly possible to<br>
> share code. I think what you've pointed out is the timeline when new<br>
> development cutover to use src/soc for all the parts as the parts<br>
> really are SoC with a close coupling of implementations. The logic<br>
> blocks inside the parts are definitely forks of one another just like<br>
> software so there is re-use at play. With your change and the other<br>
> one we'd have 2 parallel implementations that could be tested for<br>
> parity and combined. That said, one needs to be careful in the details<br>
> for determining where something can be truly common. In the smbus<br>
> stuff specifically I'm sure there has be no real modification in a<br>
> very long time, but that isn't true for all blocks.<br>
><br>
<br>
My main thought was that is a bit sad that efforts to make more code<br>
common happens in src/soc/intel/ while there is a lot in<br>
src/southbridge/intel that can be set up with identical code (but maybe<br>
smbus is indeed the only thing that can cleanly be common without too<br>
much per platform guarding).<br>
<br>
><br>
> The newer code is not separated. It's actually combined? Benefit is<br>
> one stop shopping for a given platform for code to reside instead of<br>
> laying down multiple directories in various places that doesn't<br>
> reflect the construction of the systems. That said, with the<br>
> introduction of the common modules the soc/intel directories will<br>
> become thinner with selecting the common modules. That reflects more<br>
> closely how hardware development is being done.<br>
><br>
> Though the soc/ directory layout isn't the only way of making the<br>
> following work, it certainly helps. For the purposes of porting a<br>
> board based off of another board of a different platform it makes the<br>
> code maintenance easier solely based on #include files. There's really<br>
> not reason to have to #include a/specific/directory/header to make<br>
> something work. If the abstractions are done correctly one can<br>
> #include genericpath/header with a conforming API. That allows code<br>
> reuse and porting to go more smoothly. If you are having to #ifdef<br>
> CONFIG to figure out the include path in the c files that makes the<br>
> source ugly and a maintenance burden. This isn't the only the example,<br>
> but a good one where there's a ton of #ifdef for include paths:<br>
> src/cpu/x86/smm/smmrelocate.S. That's also ignoring the "common"<br>
> headers which do or don't expose certain functions that are found in<br>
> specific places as well. In short, I think the<br>
> southbridge/cpu/northbridge split in how it's been done in the past<br>
> actually creates more of a burden. Again, that doesn't mean things<br>
> can't be fixed by using consistent and namespaced include paths.<br>
><br>
<br>
Ok thanks for the insight. Some things that were used by different<br>
IC combinations were indeed a mess with amd in particular (but that is<br>
probably because a lot of code was not linked)<br>
<br>
<br></blockquote><div><br></div><div>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. </div><div><br></div><div>Marc</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
--<br>
Arthur Heymans<br>
<br>
--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/mailman/listinfo/coreboot</a><br>
</blockquote></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><a href="http://marcjonesconsulting.com">http://marcjonesconsulting.com</a></div></div>