[U-Boot-Users] Altera Stratix II support

Andy Fleming afleming at gmail.com
Wed Jun 6 17:44:57 CEST 2007


On 6/6/07, eran liberty <eran.liberty at gmail.com> wrote:
> Most of what you have chosen to comment on is part of my new board.
> some of it is still dirty work as it is all on progress and would love
> to get code review on, but keep in mind its fairly young code.
>
> On 6/6/07, Andy Fleming <afleming at gmail.com> wrote:
> > +/* FIXME: if tsec does not work try thorwing this in (remove the if 0)*/
> > +int last_stage_init(void)
> > +{
> > +       /* TSEC0 register the first phy so we dont */
> > +       tsec_initialize(gd->bd, 1, "2");
> > +       tsec_initialize(gd->bd, 2, "3");
> > +       tsec_initialize(gd->bd, 3, "4");
> > +       tsec_initialize(gd->bd, 4, "5");
> > +       tsec_initialize(gd->bd, 5, "6");
> > +       tsec_initialize(gd->bd, 6, "7");
> > +       tsec_initialize(gd->bd, 7, "8");
> > +       tsec_initialize(gd->bd, 8, "9");
> > +       tsec_initialize(gd->bd, 9, "10");
> > +       tsec_initialize(gd->bd, 10, "11");
> > +
> > +       return 0;
> > +}
> >
> > Huh?  How can you be initializing 10 tsecs?  What part is this?
> >
> I can and i do. :)


I still debate that point.  The 8548 has *4* eTSECs.  Not 11.  At
best, you've created 11 virtual tsecs, each with a different PHY.
Though how you configure which one is physically connected is beyond
me.

> > +COBJS  := $(BOARD).o \
> > +           ft_board.o \
> > +           fpga.o \
> > +          ../../cds/common/eeprom.o \
> > +          ../../cds/common/via.o
> >
>
> I need to remove both eeprom.o via.o. I do not use them.. but as it is
> right now, removing them breaks the build. It is in my todo list.


Ok, good

> >  static struct tsec_info_struct tsec_info[] = {
> > +#if defined CONFIG_EXSW6000
> > +       {TSEC1_PHY_ADDR, TSEC_GIGABIT, TSEC1_PHYIDX},
> > +       {2, TSEC_GIGABIT, 1},
> > +       {3, TSEC_GIGABIT, 2},
> > +       {4, TSEC_GIGABIT, 3},
> > +       {5, TSEC_GIGABIT, 4},
> > +       {6, TSEC_GIGABIT, 5},
> > +       {7, TSEC_GIGABIT, 6},
> > +       {8, TSEC_GIGABIT, 7},
> > +       {9, TSEC_GIGABIT, 8},
> > +       {10, TSEC_GIGABIT, 9},
> > +       {11, TSEC_GIGABIT, 10},
> > +#else
> >
>
> I thought i am doing something shady as well stacking all mdio on the
> register of tsec0... but then i moved on to linux and saw they do
> exactly the same. :)


Yes, because only tsec0's MDIO pins are exposed from the package.  The
others only connect to the internal TBI PHY, which is useful for
certain things, but that's not what you've done here.


> > 2) I am *very* confused by what you did, here.  Now it looks like you
> > have set the phyregs back to what would happen if your phyregidx had
> > been 0.  And all of your TSECs share a single register set.  It looks
> > like you have one TSEC and 11 PHYs.  What's going on?
> >
>
> very simple. All mdio are accessed via the same registers. the one
> that are in the memory space of eTSEC0


Yes, that's what phyregidx is for.  It defines which registers are
used for PHY accesses.  But you've also set up 11 tsecs all using the
same register space.  That's overkill.  It looks like you have one
tsec, and you want to be able to choose which PHY it is using by
creating one driver instances for each PHY.  So all you really need is
one driver instance, and the ability to change which PHY the tsec
configures.  That shouldn't be too  difficult.

If I'm wrong, then I'm still confused as to what the code changes to
tsec are doing.

Andy




More information about the U-Boot mailing list