Re: MPC5200 fec frame corruption

[Sylvain Munaut <tnt@246tNt.com>]

Hi Asier,
> We have been working with the MPC5200 fec and a linux-2.6.10 with some
> patches extracted from Sylvain's bitkeeper repository. We have 3
> different boards that worked properly with that kernel.
>
> We upgraded to the new MPC5200B and it still worked properly with the
> 2.6.10 kernel.
>
> We upgraded to the new code of the Sylvain's git repository and the FEC
> transmitted frames are corrupted. This corruption only happens with the
> current git repository and the MPC5200B.
>
>                 MPC5200   MPC5200B
> linux-2.6.10:     OK         OK
> Sylvain's git:    OK       CORRUPT
>   
I must admit I don't have bitkeeper anymore installed on my machine so I
don't
remeber exactly what in there.

Could you put somewhere on line the diff between 2.6.10 and you tree,
eventually minus all the irrelevant/confidential stuff ?
What would be needed woud be the arch/ppc/syslib/bestcomm ,
drivers/net/fec_mpc52xx
and the board setup code.
> The problem is that the lite5200 and the lite5200b work flawlessly, but
> our architecture is essentialy the same but with different PHYs (Marvell
> 88E6095F and 88E6060). Our architecture works properly with the
> linux-2.6.10, so we don't think that it is a hardware related problem.
> We have been watching the MII bus by osciloscope and the errors are
> clearly transmitted by the MPC5200B (no noise or distortion).
>
> We have inserted traces in the functions of the FEC driver with the
> buffer information that is sent to the DMA and the frames are correct.
>
>
> [... logs stripped ...]
> The corrupted bytes are sometimes correct, sometimes overwriten
> by the byte that is 0x20 bytes before, and sometimes changed
> by the bytes that is 0x40 bytes before. About 50% of the time
> the marked bytes are worong.
>
> I'd like to know if anything here makes any sense to you, so
> that I can understand the origin of the problem, or any
> additional test to perform.
>   
Any sense not really. But I would check first the options in the board
setup.
Things like cache snooping, comm bus prefetching, xlb priority settings and
pipelining, ...

Then the microcode of the task themselves and the options wich are used when
loading them.

Finally compare the driver code itself.


        Sylvain