there's another way to do this that few people use.
Back in the E7500 days, the 7505 came along. We experimented with this: src/northbridge/intel/e750x and put the common files in there. Under e750x we had e7500 e7505
for the different files. so, src/northbridge/intel/e750x/{e7500,e7505} worked fine. nobody cared enough to really do the work of putting it all together, we were just happy that the build system supported the naming in the files and so on. Part of the trick is this: in the mainboard file, the part becomes src/northbridge/intel/e750x/e7500 and in e7500 you include parts from src/northbridge/intel/e750x
So you don't make e750x the northbridge directory; rather you make e750x/e7505 and e750x/e7500 the directory. That way, no condition includes or anything. It's a pretty standard build setup.
this is similar to what we did on the ARM parts a few years back.
ron
On Mon, Dec 7, 2015 at 4:08 PM Ben Gardner gardner.ben@gmail.com wrote:
On Mon, Dec 7, 2015 at 9:55 AM, Martin Roth gaumless@gmail.com wrote:
I think we can cut down on some of the code redundancy, but as Alex says, they are different chipsets, and we need to be careful about trying to combine too much.
Here are my suggested steps:
- Look for commonalities between baytrail and other chipsets and move
pieces things into soc/intel/common or southbridge/intel/common. Let's not do a bunch of work just for baytrail that could help all the intel chipsets. I think this should be done regardless of anything that we decide about Bay Trail.
- Figure out which changes in each directory should go to the other.
Each have gotten some fixes that should be shared with the other directory.
- Make the baytrail directory structures look as similar again -
rename the soc/fsp_baytrail/baytrail include directory to soc/fsp_baytrail/soc/include to match what was done with soc/baytrail. Or we can rename them both to just soc/(fsp_)baytrail/include. Something, so long as they match.
- Create a soc/intel/baytrail_common or soc/intel/baytrail/common
directory and move pieces that are the same for both chipsets into those directories. Work on consolidation, and getting as much as is reasonable into that directory. I'd prefer not to just leave files in soc/intel/baytrail because then it's not obvious that the files are shared between the two platforms.
Similar steps could be done for the other fsp/non-fsp directories: cpu/(fsp_)model_206ax, northbridge/(fsp_)sandybridge, and southbridge/intel/(fsp_)bd82x6x.
Ben, Michael, Since you seem to be actively working in this code, how do you feel about this?
I'm OK with reducing duplication and unnecessary differences. There seems to be plenty of duplicate header files. Without a similar tree structure and filenames, it is difficult to compare the trees, so I'd sync that first.
I'd prefer seeing common baytrail stuff in soc/intel/baytrail_common/ vs under baytrail/common.
Ben
Martin
On Sun, Dec 6, 2015 at 11:54 PM, Alex G. mr.nuke.me@gmail.com wrote:
On 12/06/2015 08:18 AM, Alexander Couzens wrote:
hi,
baytrail and fsp_baytrail shares a lot of code. Any ideas how we can merge these?
That's not a very good idea. There are different sets of interest which use those two code paths, and trying to unify that will only get people stepping on each others toes.
At most, you can make fsp_baytrail/ use the CPU part of baytrail/, but leave the northbridge and southbridge parts alone.
My advice, just stash the fsp_baytrail/ in some dark basement and forget about it. If it gets in the way or gives you trouble, let me know, but otherwise, just pretend it doesn't exist
Alex
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-
ron minnich