8360 custom board, ucc_geth TX errors on longer(?) packets

8360 custom board, ucc_geth TX errors on longer(?) packets

[Steven Hein]

Hi All:

For our custom 8360-based board that is based fairly closely
on the MPC8360-MDS board, I'm working on moving from a 2.6.16
kernel (Timesys distro) to 2.6.24.   I didn't use the device
tree in my old kernel, so I've had the learning experience
of tweaking the dts file for my custom board.  I've got it 99%
working  (I think!).   But I'm running into a really odd ethernet
problem that I don't understand.

I have two boards:  our custom 8360 board, and a MPC8360E-MDS
dev board.    I can build a kernel for the MDS board and
ethernet works perfectly.    When I build that kernel using the
same config, but changing the platform to my custom board
(and not changing any other options), everything works right
except for ethernet:    it won't get an IP address using DHCP
(udhcpc)...    I check the ifconfig output, and I see that
the TX error count is increasing, and there are very few TX
packets being sent.   I verified that this isn't a timeout--
it's being caused by the UCCE[TXE] bit being set   (I don't see
any other error indications in dmesg).

As another test, I configured the address manually.   When I do
that, I can ping the board with a normal ping; but if I use
the -s option to increase the packet size, then the pings will
fail when I use a size of about 250 or greater, and with a size
of about 300 or greater I get no successful ping packets.

The one main difference in this board is how eth0 is wired.
We have a Broadcom GbE switch part, and UCC1 eth is wired
directly to that switch (no PHY).   (This where I needed to
use the fixed-link option that I had asked about a couple of
days ago!).   In my 2.6.16-based kernel, I had created a
dummy "null" PHY to force the link speed to 1000, and that
worked well.    I am using the same Broadcom network
switch software with both kernels, so the switch side of the
config should be the same.

I created my custom board config from the MPC8360E-MDS board
configs (starting with that defconfig, dts, and platform .c
file), and matched my GPIO pin configs in the dtb file to what
I had used in the 2.6.16 kernel......  I'm not sure where to
look for this problem, as I've never seen UCCE[TXE] set
before.    Based on my experience in this move so far, I'd
guess that I've got something configured wrong somewhere,
but I just don't know where to look.

Does anyone have any ideas/suggestions?
Any help would be MUCH appreciated!!

Thanks,
Steve

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Hein (ssh@sgi.com)              Engineering Diagnostics/Software
Silicon Graphics, Inc.                          
1168 Industrial Blvd.                 Phone: (715) 726-8410
Chippewa Falls, WI 54729              Fax:   (715) 726-6715
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: 8360 custom board, ucc_geth TX errors on longer(?) packets

[Kim Phillips]

On Fri, 01 Feb 2008 12:52:25 -0600
Steven Hein <ssh@sgi.com> wrote:

> The one main difference in this board is how eth0 is wired.
> We have a Broadcom GbE switch part, and UCC1 eth is wired
> directly to that switch (no PHY).   (This where I needed to

sounds like you ran into some h/w errata.  if on rgmii, you might
want to find a way to program the switch for rgmii with internal delay
(8360 rev.2 rgmii-id rx & tx; 8360rev2.1 rgmii-rxid (i.e. for rx
only)).  If not, I'd contact fsl tech support directly.

Kim

Re: 8360 custom board, ucc_geth TX errors on longer(?) packets

[Steven Hein]

Kim Phillips wrote:
> On Fri, 01 Feb 2008 12:52:25 -0600
> Steven Hein <ssh@sgi.com> wrote:
>
>   
>> The one main difference in this board is how eth0 is wired.
>> We have a Broadcom GbE switch part, and UCC1 eth is wired
>> directly to that switch (no PHY).   (This where I needed to
>>     
>
> sounds like you ran into some h/w errata.  if on rgmii, you might
> want to find a way to program the switch for rgmii with internal delay
> (8360 rev.2 rgmii-id rx & tx; 8360rev2.1 rgmii-rxid (i.e. for rx
> only)).  If not, I'd contact fsl tech support directly.
>
> Kim
>   

I would suspect HW.....but this WORKS with the 2.6.16 kernel
I was using!    That's why I suspect that I still don't have
something configured right in my device tree, or something
else I missed in the new kernel.    But I can't
figure out what it is.... :-(    I've poured over the code in
the old versus new (both the ucc_geth driver and the platform
initialization in the old, and the device tree in the new)
and can't figure out what I missed!   And like I said, a
kernel with the same config (other than changing the platform)
works on my MPC8360E-MDS board.   Granted, that doesn't have
this direct switch connection......

I did look at the code related to the HW errata (QE_ENET18).
But we're using GMII to the switch....and that workaround
code wasn't in active in my old kernel (it was there, but
commented out).

Any other thoughts?    Has anyone seen this symptom before?

Steve

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Hein (ssh@sgi.com)              Engineering Diagnostics/Software
Silicon Graphics, Inc.                          
1168 Industrial Blvd.                 Phone: (715) 726-8410
Chippewa Falls, WI 54729              Fax:   (715) 726-6715
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: 8360 custom board, ucc_geth TX errors on longer(?) packets

[Steven Hein]

Steven Hein wrote:
> Kim Phillips wrote:
>> On Fri, 01 Feb 2008 12:52:25 -0600
>> Steven Hein <ssh@sgi.com> wrote:
>>
>>  
>>> The one main difference in this board is how eth0 is wired.
>>> We have a Broadcom GbE switch part, and UCC1 eth is wired
>>> directly to that switch (no PHY).   (This where I needed to
>>>     
>>
>> sounds like you ran into some h/w errata.  if on rgmii, you might
>> want to find a way to program the switch for rgmii with internal delay
>> (8360 rev.2 rgmii-id rx & tx; 8360rev2.1 rgmii-rxid (i.e. for rx
>> only)).  If not, I'd contact fsl tech support directly.
>>
>> Kim
>>   
>
> I would suspect HW.....but this WORKS with the 2.6.16 kernel
> I was using!    That's why I suspect that I still don't have
> something configured right in my device tree, or something
> else I missed in the new kernel.    But I can't
> figure out what it is.... :-(    I've poured over the code in
> the old versus new (both the ucc_geth driver and the platform
> initialization in the old, and the device tree in the new)
> and can't figure out what I missed!   And like I said, a
> kernel with the same config (other than changing the platform)
> works on my MPC8360E-MDS board.   Granted, that doesn't have
> this direct switch connection......
>
> I did look at the code related to the HW errata (QE_ENET18).
> But we're using GMII to the switch....and that workaround
> code wasn't in active in my old kernel (it was there, but
> commented out).
>
> Any other thoughts?    Has anyone seen this symptom before?
>
> Steve
>
Okay....I found it!    Started poking at the UCCE registers
and found that the FIFO sizes weren't right.   This led me
to find a bug in my ucc_geth interface to the fixed-link
PHY driver:  the code to reconfigure the MURAM FIFO's for
Gigabit operation wasn't being executed for no-phy configs!
All is well once I changed this.

Sorry for the noise.....   (glad I found this before
submitting my patch!   ;-)

Steve

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Hein (ssh@sgi.com)              Engineering Diagnostics/Software
Silicon Graphics, Inc.                          
1168 Industrial Blvd.                 Phone: (715) 726-8410
Chippewa Falls, WI 54729              Fax:   (715) 726-6715
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: 8360 custom board, ucc_geth TX errors on longer(?) packets

[Kim Phillips]

On Fri, 01 Feb 2008 16:06:15 -0600
Steven Hein <ssh@sgi.com> wrote:

> Steven Hein wrote:
> > But we're using GMII to the switch....and that workaround
> > code wasn't in active in my old kernel (it was there, but
> > commented out).
> >
> > Any other thoughts?    Has anyone seen this symptom before?
> >
> > Steve
> >
> Okay....I found it!    Started poking at the UCCE registers
> and found that the FIFO sizes weren't right.   This led me
> to find a bug in my ucc_geth interface to the fixed-link
> PHY driver:  the code to reconfigure the MURAM FIFO's for
> Gigabit operation wasn't being executed for no-phy configs!
> All is well once I changed this.
> 
> Sorry for the noise.....   (glad I found this before
> submitting my patch!   ;-)
> 
yeah ucc_geth should be made aware of fixed-links on startup; UCCs
aren't like TSECs that know what MII type they're on.

setting phy-connection-type to certain strings containing a
'g' in the device tree should do the trick, too..:)

Kim