Andrew,
What I have already done should be able to handle your situation,
assuming you can identify the two processor variants with a 32-bit
integer or a string. In your board code you determine which variant
you are and then the device list will get registered based on that.
- kumar
On Jan 14, 2005, at 1:13 PM, Andrew May wrote:
> On Wed, 2005-01-12 at 14:14 -0700, Matt Porter wrote:
> > On Wed, Jan 12, 2005 at 12:36:37AM -0800, Eugene Surovegin wrote:
> > > On Wed, Jan 12, 2005 at 01:43:09AM -0600, Kumar Gala wrote:
> > >
> > > In fact, I don't see any gain (at least for 4xx) in all these
> changes.
> > > It makes 4xx much more tangled IMHO, because we'll still need all
> > > those ibm405gp.c, ibm405ep.c, ibm440gp.c etc.
> >
> > Summarizing some stuff from IRC (now that I'm caught up after time
> > off :P), I think we can live with this on 4xx. What seems to be
> > acceptable is that we can have an soc_specs[] and
> soc_platform_devices[]
> > in each 4xx SoC platform file. So, core_ocp[] can be merged and split
> > into soc_specs[]/soc_platform_devices[]. The active one will be
> selected
> > at build time just like we do now. This is due to the static nature
> > of the 4xx memory map (per SoC) and well as the variation in
> location
> > of iomem and irq resources as well as platform_data. Our soc_specs[]
> > will only have one SoC in it, since there is one per file. Doing
> > something like 85xx will scatter info about as you point out
> > above...and that doesn't make sense for 4xx.
>
> I would like to bring the Virtex-II Pro, into the thinking as well. It
> is an FPGA around the 405 so it can be much more flexible on what
> makes
> up the SoC.
>
> I am stuck working on 2.4 for a non-released product (so no code to
> submit) and we have 2 of these chips on 1 board.
>
> One has only 1 UART and the other has 2. The rest of the standard
> devices are the same, but they all have different IRQ mappings.
>
> I really don't want to build 2 different kernels just to handle this.
> So
> far I have just overwritten the OCP struct at boot time to deal with
> it,
> based on a HW reg that tells me which chip I am running on. I also did
> a kernel cmd line option saved in u-boot before I got the HW reg.
>
> If FPGAs start to make up more of the SoC market it don't think a
> simple
> array of the devices is a good model to have. The FPGA could be loaded
> differently for special modes with a very different setup.
>
> I am not sure what the trade off should be for the simple build time
> array compared to the run time list that is built up.
>
> Would something like this be OK?
>
> struct chip_basic_features[] = { {}, {},....... };
>
> struct chip_ext1_features[] = { {}, {},....... };
> struct chip_ext2_features[] = { {}, {},....... };
>
> LIST_HEAD(system_features);
>
>
>
> board_init()
> {
> ??????? list_add_tail( &system_features, &chip_basic_features );
>
> ??????? if( board1 ){
> ??????? ??????? list_add_tail( &system_features, &chip_ext1_features
> );
> ??????? }else{
> ??????? ??????? list_add_tail( &system_features, &chip_ext2_features
> );
> ??????? }
> }
