[U-Boot] FW: ARM Pull Request

[U-Boot] FW: ARM Pull Request

[Prafulla Wadaskar]

> > > Prafulla Wadaskar (3):
> > >       Marvell Sheevaplug Board support
> > >       Marvell MV88F6281GTW_GE Board support
> > >       Marvell RD6281A Board support
Hi Ben,
I think Pull request net not yet applied.
This breaks build for RD6281A board.

Some discussion was going for
"net: Kirkwood_egiga: forced interface speed config support" patch inclusion.
Jean has voted to keep this patch. Ref http://lists.denx.de/pipermail/u-boot/2009-July/057139.html
even if wolfgang decides to skip this patch, rest other should be applied.

Thanks and Regards..
Prafulla . .

[U-Boot] FW: ARM Pull Request

[Ben Warren]

Prafulla Wadaskar wrote:
>>>> Prafulla Wadaskar (3):
>>>>       Marvell Sheevaplug Board support
>>>>       Marvell MV88F6281GTW_GE Board support
>>>>       Marvell RD6281A Board support
>>>>         
> Hi Ben,
> I think Pull request net not yet applied.
> This breaks build for RD6281A board.
>
> Some discussion was going for
> "net: Kirkwood_egiga: forced interface speed config support" patch inclusion.
> Jean has voted to keep this patch. Ref http://lists.denx.de/pipermail/u-boot/2009-July/057139.html
> even if wolfgang decides to skip this patch, rest other should be applied.
>
> Thanks and Regards..
> Prafulla . .
>   
I'm working on the repo right now and should have another pull request 
soon.  The 'forced interface' patch is still contentious, so isn't included.

regards,
Ben

[U-Boot] FW: ARM Pull Request

[Prafulla Wadaskar]

 

> -----Original Message-----
> From: Ben Warren [mailto:biggerbadderben at gmail.com] 
> Sent: Thursday, July 23, 2009 11:40 AM
> To: Prafulla Wadaskar
> Cc: Wolfgang Denk; U-Boot; Jean-Christophe PLAGNIOL-VILLARD; 
> Ashish Karkare; Prabhanjan Sarnaik
> Subject: Re: FW: [U-Boot] ARM Pull Request
> 
> Prafulla Wadaskar wrote:
> >>>> Prafulla Wadaskar (3):
> >>>>       Marvell Sheevaplug Board support
> >>>>       Marvell MV88F6281GTW_GE Board support
> >>>>       Marvell RD6281A Board support
> >>>>         
> > Hi Ben,
> > I think Pull request net not yet applied.
> > This breaks build for RD6281A board.
> >
> > Some discussion was going for
> > "net: Kirkwood_egiga: forced interface speed config 
> support" patch inclusion.
> > Jean has voted to keep this patch. Ref 
> > http://lists.denx.de/pipermail/u-boot/2009-July/057139.html
> > even if wolfgang decides to skip this patch, rest other 
> should be applied.
> >
> > Thanks and Regards..
> > Prafulla . .
> >   
> I'm working on the repo right now and should have another 
> pull request soon.  The 'forced interface' patch is still 
> contentious, so isn't included.
Okay
With this for RD6281 Build will not fail, but network will be broken.
Meanwhile I will check why auto negotiation doesn't work on this board?

Regards..
Prafulla . .

> 
> regards,
> Ben
> 

[U-Boot] FW: ARM Pull Request

[Ben Warren]

Prafulla Wadaskar wrote:
>  
>
>   
>> -----Original Message-----
>> From: Ben Warren [mailto:biggerbadderben at gmail.com] 
>> Sent: Thursday, July 23, 2009 11:40 AM
>> To: Prafulla Wadaskar
>> Cc: Wolfgang Denk; U-Boot; Jean-Christophe PLAGNIOL-VILLARD; 
>> Ashish Karkare; Prabhanjan Sarnaik
>> Subject: Re: FW: [U-Boot] ARM Pull Request
>>
>> Prafulla Wadaskar wrote:
>>     
>>>>>> Prafulla Wadaskar (3):
>>>>>>       Marvell Sheevaplug Board support
>>>>>>       Marvell MV88F6281GTW_GE Board support
>>>>>>       Marvell RD6281A Board support
>>>>>>         
>>>>>>             
>>> Hi Ben,
>>> I think Pull request net not yet applied.
>>> This breaks build for RD6281A board.
>>>
>>> Some discussion was going for
>>> "net: Kirkwood_egiga: forced interface speed config 
>>>       
>> support" patch inclusion.
>>     
>>> Jean has voted to keep this patch. Ref 
>>> http://lists.denx.de/pipermail/u-boot/2009-July/057139.html
>>> even if wolfgang decides to skip this patch, rest other 
>>>       
>> should be applied.
>>     
>>> Thanks and Regards..
>>> Prafulla . .
>>>   
>>>       
>> I'm working on the repo right now and should have another 
>> pull request soon.  The 'forced interface' patch is still 
>> contentious, so isn't included.
>>     
> Okay
> With this for RD6281 Build will not fail, but network will be broken.
> Meanwhile I will check why auto negotiation doesn't work on this board?
>   
Seems like a good plan.

Ben

[U-Boot] FW: ARM Pull Request

[Stefan Roese]

On Thursday 23 July 2009 08:16:47 Prafulla Wadaskar wrote:
> > I'm working on the repo right now and should have another
> > pull request soon.  The 'forced interface' patch is still
> > contentious, so isn't included.
>
> Okay
> With this for RD6281 Build will not fail, but network will be broken.
> Meanwhile I will check why auto negotiation doesn't work on this board?

Did you check if Lennert's comments are correct?

Quote:
>Isn't it just because on the RD6281A, the first ethernet MAC of the
>CPU is connected to an ethernet switch chip instead of an ethernet PHY,
>and therefore there is no negotiation to be done?  (The second MAC
>is connected to a PHY directly, so that one should just use autoneg.)
>
>Even on the RD6281Z, we should just force the ethernet MAC to a
>fixed speed/duplex, since even though PHY polling might work there,
>we'll be talking to the PHY corresponding to the first switch port,
>which means that you might not be able to tftp from the second switch
>port or so if there's nothing plugged into the first one.
>
>FWIW, the linux kernel port also forces 1000/full on the CPU MACs where
>a switch chip is connected.  On those CPU MACs where there is a switch
>chip connected, the (R)(G)MII interface becomes purely a bus to
>transport packets into and out of the crossbar, one that is always up.

So, is this ethernet port in question connected to switch? Then a forced link 
(highest speed) should be used.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] FW: ARM Pull Request

[Prafulla Wadaskar]

 

> -----Original Message-----
> From: Stefan Roese [mailto:sr at denx.de] 
> Sent: Thursday, July 23, 2009 11:57 AM
> To: u-boot at lists.denx.de
> Cc: Prafulla Wadaskar; Ben Warren; Ashish Karkare; Prabhanjan Sarnaik
> Subject: Re: [U-Boot] FW: ARM Pull Request
> 
> On Thursday 23 July 2009 08:16:47 Prafulla Wadaskar wrote:
> > > I'm working on the repo right now and should have another
> > > pull request soon.  The 'forced interface' patch is still
> > > contentious, so isn't included.
> >
> > Okay
> > With this for RD6281 Build will not fail, but network will 
> be broken.
> > Meanwhile I will check why auto negotiation doesn't work on 
> this board?
> 
> Did you check if Lennert's comments are correct?
Dear Stefan
Yes, I have checked.

> 
> Quote:
> >Isn't it just because on the RD6281A, the first ethernet MAC of the
> >CPU is connected to an ethernet switch chip instead of an 
> ethernet PHY,
> >and therefore there is no negotiation to be done?
But auto negotiation works with other board for similar case (i.e. mv88f6281gtw_ge)
Only the difference is on rd6281A multichip addressing mode is used.
I cannot comment much on this at this moment, this is my observation.
So I was planning to debug this part.
 
  (The second MAC
> >is connected to a PHY directly, so that one should just use autoneg.)
Yes, this is functional on egiga1

> >
> >Even on the RD6281Z, we should just force the ethernet MAC to a
> >fixed speed/duplex, since even though PHY polling might work there,
> >we'll be talking to the PHY corresponding to the first switch port,
> >which means that you might not be able to tftp from the second switch
> >port or so if there's nothing plugged into the first one.
> >
> >FWIW, the linux kernel port also forces 1000/full on the CPU 
> MACs where
> >a switch chip is connected.  On those CPU MACs where there 
> is a switch
> >chip connected, the (R)(G)MII interface becomes purely a bus to
> >transport packets into and out of the crossbar, one that is 
> always up.
> 
> So, is this ethernet port in question connected to switch? 
> Then a forced link 
> (highest speed) should be used.
This is what I was trying to do,
but it was through CONGIF_ options and that is applied to both ports,
in case we need to force link speed then I need to provide some configurable interface
for u-boot kirkwood egiga driver.

Regards..
Prafulla . .
 
> 
> Best regards,
> Stefan
> 
> =====================================================================
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
> =====================================================================
> 

[U-Boot] FW: ARM Pull Request

[Stefan Roese]

On Thursday 23 July 2009 08:44:57 Prafulla Wadaskar wrote:
> > So, is this ethernet port in question connected to switch?
> > Then a forced link
> > (highest speed) should be used.
>
> This is what I was trying to do,
> but it was through CONGIF_ options and that is applied to both ports,
> in case we need to force link speed then I need to provide some
> configurable interface for u-boot kirkwood egiga driver.

We have such an "interface" in the PPC4xx ethernet driver:

drivers/net/4xx_enet.c:

/*--------------------------------------------------------------------+
 * Fixed PHY (PHY-less) support for Ethernet Ports.
 *--------------------------------------------------------------------*/

/*
 * Some boards do not have a PHY for each ethernet port. These ports
 * are known as Fixed PHY (or PHY-less) ports. For such ports, set
 * the appropriate CONFIG_PHY_ADDR equal to CONFIG_FIXED_PHY and
 * then define CONFIG_SYS_FIXED_PHY_PORTS to define what the speed and
 * duplex should be for these ports in the board configuration
 * file.
 *
 * For Example:
 *     #define CONFIG_FIXED_PHY   0xFFFFFFFF
 *
 *     #define CONFIG_PHY_ADDR    CONFIG_FIXED_PHY
 *     #define CONFIG_PHY1_ADDR   1
 *     #define CONFIG_PHY2_ADDR   CONFIG_FIXED_PHY
 *     #define CONFIG_PHY3_ADDR   3
 *
 *     #define CONFIG_SYS_FIXED_PHY_PORT(devnum,speed,duplex) \
 *                     {devnum, speed, duplex},
 *
 *     #define CONFIG_SYS_FIXED_PHY_PORTS \
 *                     CONFIG_SYS_FIXED_PHY_PORT(0,1000,FULL) \
 *                     CONFIG_SYS_FIXED_PHY_PORT(2,100,HALF)
 */

#ifndef CONFIG_FIXED_PHY
#define CONFIG_FIXED_PHY	0xFFFFFFFF /* Fixed PHY (PHY-less) */
#endif

#ifndef CONFIG_SYS_FIXED_PHY_PORTS
#define CONFIG_SYS_FIXED_PHY_PORTS	/* default is an empty array */
#endif

struct fixed_phy_port {
	unsigned int devnum;	/* ethernet port */
	unsigned int speed;	/* specified speed 10,100 or 1000 */
	unsigned int duplex;	/* specified duplex FULL or HALF */
};

static const struct fixed_phy_port fixed_phy_port[] = {
	CONFIG_SYS_FIXED_PHY_PORTS	/* defined in board configuration file 
*/
};


And include/configs/canyonlands.h:

#define CONFIG_FIXED_PHY	0xFFFFFFFF
#define CONFIG_PHY_ADDR		CONFIG_FIXED_PHY

#define CONFIG_SYS_FIXED_PHY_PORT(devnum, speed, duplex) \
		{devnum, speed, duplex}
#define CONFIG_SYS_FIXED_PHY_PORTS \
		CONFIG_SYS_FIXED_PHY_PORT(0, 1000, FULL)



It's definitely not perfect but perhaps you could re-use it for your problem 
as well.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] FW: ARM Pull Request

[Lennert Buytenhek]

On Wed, Jul 22, 2009 at 11:44:57PM -0700, Prafulla Wadaskar wrote:

> > >Isn't it just because on the RD6281A, the first ethernet MAC of the
> > >CPU is connected to an ethernet switch chip instead of an 
> > ethernet PHY,
> > >and therefore there is no negotiation to be done?
>
> But auto negotiation works with other board for similar case (i.e.
> mv88f6281gtw_ge)
> Only the difference is on rd6281A multichip addressing mode is used.
> I cannot comment much on this at this moment, this is my observation.
> So I was planning to debug this part.

In single-chip address mode, you'll still only be talking to one of
the five PHYs that the switch chip has, and things like forcing link
modes or checking whether the link is up will only work on one of
the five ports.

So if you're checking the PHY registers to make sure the link is up
before you e.g. start sending DHCP requests, then that won't do what
you want even though it will appear to work in single-chip address
mode.

If you're providing a way to force certain ports to certain speeds
from the uboot command line, then you should ideally just implement
multi-chip addressing mode and allow access to the individual PHYs,
I guess.