> -----Original Message----- > From: Albert ARIBAUD [mailto:albert.arib...@free.fr] > Sent: Friday, August 06, 2010 12:39 PM > To: Prafulla Wadaskar > Cc: Wolfgang Denk; u-boot@lists.denx.de; Ashish Karkare; > Prabhanjan Sarnaik > Subject: Re: [PATCH V7 0/4] Add disk support to orion5x and edminiv2 > > Le 05/08/2010 20:37, Prafulla Wadaskar a écrit : > > > > > >> -----Original Message----- > >> From: u-boot-boun...@lists.denx.de > >> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk > >> Sent: Thursday, August 05, 2010 11:55 PM > >> To: Albert ARIBAUD > >> Cc: u-boot@lists.denx.de > >> Subject: Re: [U-Boot] [PATCH V7 0/4] Add disk support to > >> orion5x and edminiv2 > >> > >> Dear Albert ARIBAUD, > >> > >> In message<4c5ad4f7.2030...@free.fr> you wrote: > >>> > >>> As for the configs, some u-boot boards do commonalize, see > >> for instance > >>> include/configs/spear*.h. That makes sense because there > is a board > >>> family, with a common HW design and common external components. > >> > >> This is not actually a prerequisite. You can create a > common look and > >> feel across completely different boards and architectures. > >> > >> For example, include/configs/amcc-common.h provides a > common look and > >> feel for all boards by one specific vendor. > > > > That's good idea to generate mv-common.h to abstract > Marvell (kirkwood+orion > > specific )common definitions across the boards > > Why not? The only drawback would be that some board would > want to use a > config different from what the common config has set (e.g., an Orion > board with no MVSATAHC) but even then, the board config file would > simply not include the common config, or include it and undefine or > redefine some config elements. > > Two (independant) comments: > > 1. If abstracting SoC configuration (which I'm fine with), maybe it > would make more sense to abstract by SoC (i.e., kirkwood-common.h, > orion5x-common.h...) -- or even by IP (i.e. mvgbe-common.h, > mvsata-common.h...) rather than by "commonality". > > 2. Would it be worthwhile, from a readability/maintenability > standpoint, > to generalize the idea of SoC- and board-specific configs, > and thus have > board-specific includes in one directory and SoC-specific includes in > another?
Any System = f(board, soc). We have board configs header file in place. Just having soc-config header file would be enough, We should have <asm/arch/config.h> included within board config file. Any unwanted stuff can be undefed below it. Regards.. Prafulla . . _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot