[U-Boot] Malformed ARP packets

[U-Boot] Malformed ARP packets

[Remi Lefevre]

Hello,

I ported U-Boot on my custom MPC8270 board.
Everything seems to go well but my ARP packets are malformed:

=> ping 192.168.0.1
Trying FCC1 ETHERNET
Using FCC1 ETHERNET device
sending ARP for c0a80001
ARP broadcast 1
cycles: 25 status: 6c00
ARP broadcast 2
cycles: 20 status: 6c00
ping failed; host 192.168.0.1 is not alive

[60 bytes on wire]                                            <- correct
          correct broadcast  correct mac addr   ARP type
          ----------------- ------------------ -----------
00000000  ff ff ff ff ff ff da b0  4e 0f 0a 26 08 06 00 01  | <- correct
00000010  4e 0f 0a 26 08 06 00 01  4e 0f 0a 26 08 06 00 01  | <- malformed
00000020  00 00 00 00 00 00 c0 a8  00 01 00 00 00 00 00 00  | <- correct
00000030  c0 a8 00 01 00 00 00 00  00 00 00 01              | <- malformed
0000003c

The source mac address seems incorrectly and partially duplicated at
byte 16. Data is not random, but duplicated or mispositioned.

I saw the following thread:
http://lists.denx.de/pipermail/u-boot/2008-January/028159.html

So I checked and double-checked my SDRAM configuration but cannot
find anything wrong. I also get the same results in BBI or PBI.

MII monitoring works correctly:
=> mii dump

miiphy_read(0x0) @ 0x1 = 0x2100
0.     (2100)                 -- PHY control register --
  (8000:0000) 0.15    =     0    reset
  (4000:0000) 0.14    =     0    loopback
  (2040:2000) 0. 6,13 =   b01    speed selection = 100 Mbps
  (1000:0000) 0.12    =     0    A/N enable
  (0800:0000) 0.11    =     0    power-down
  (0400:0000) 0.10    =     0    isolate
  (0200:0000) 0. 9    =     0    restart A/N
  (0100:0100) 0. 8    =     1    duplex = full
  (0080:0000) 0. 7    =     0    collision test enable
  (003f:0000) 0. 5- 0 =     0    (reserved)

=> bdinfo
bd address  = 0x07BA3FB4
memstart    = 0x00000000
memsize     = 0x08000000
flashstart  = 0xF4000000
flashsize   = 0x02000000
flashoffset = 0x00033000
sramstart   = 0x00000000
sramsize    = 0x00000000
immr_base   = 0xF0000000
bootflags   = 0x00000001
vco         = 580.608 MHz
sccfreq     = 145.152 MHz
brgfreq     = 145.152 MHz
intfreq     = 414.720 MHz
cpmfreq     = 290.304 MHz
busfreq     = 82.944 MHz
ethaddr     = DA:B0:4E:0F:0A:26
IP addr     = 192.168.0.42
baudrate    = 115200 bps


Anything I could have forgotten to check ?

Best regards,
R?mi Lefevre

[U-Boot] Malformed ARP packets

[Jerry Van Baren]

Remi Lefevre wrote:
> Hello,
> 
> I ported U-Boot on my custom MPC8270 board.
> Everything seems to go well but my ARP packets are malformed:

[snip]

> [60 bytes on wire]                                            <- correct
>           correct broadcast  correct mac addr   ARP type
>           ----------------- ------------------ -----------
> 00000000  ff ff ff ff ff ff da b0  4e 0f 0a 26 08 06 00 01  | <- correct
> 00000010  4e 0f 0a 26 08 06 00 01  4e 0f 0a 26 08 06 00 01  | <- malformed
> 00000020  00 00 00 00 00 00 c0 a8  00 01 00 00 00 00 00 00  | <- correct
> 00000030  c0 a8 00 01 00 00 00 00  00 00 00 01              | <- malformed
> 0000003c
> 
> The source mac address seems incorrectly and partially duplicated at
> byte 16. Data is not random, but duplicated or mispositioned.
> 
> I saw the following thread:
> http://lists.denx.de/pipermail/u-boot/2008-January/028159.html
> 
> So I checked and double-checked my SDRAM configuration but cannot
> find anything wrong. I also get the same results in BBI or PBI.

Is this DIMM memory sticks with using SPD configuration or are the SDRAM 
chips soldered to the board?

This really smells of misconfigured SDRAM where your SDRAM *timing* is 
wrong.  It really looks like your DMA engine is latching the "next" bus 
cycle while your SDRAM is still presenting the previous data.  IOW, your 
memory is slower than your SDRAM controller is configured for.

Did you verify the SDRAM databook timing vs. what you configured your 
SDRAM controller to do?  Did the hardware engineer that made the board 
verify your configuration?  Did he give you a good configuration?  If 
so, are you sure it is good??? (never trust the hardware weenies ;-)

Did you read and understand <http://www.denx.de/wiki/view/DULG/SDRAM> ?

If you are sure of the timing, I would suggest you write a simple test 
application that DMAs from flash to RAM and verifies it, DMAs from RAM 
to RAM and verifies it, if possible do two simultaneous DMAs from A->B 
and C->D so that you are exercising the SDRAM pipelining vigorously.

> MII monitoring works correctly:
> => mii dump

This is meaningless for the problem at hand.  The problem is the DMA 
from SDRAM into the ethernet MAC is messed up.  You are messed up before 
the PHY gets in the picture.

[snip]

> Anything I could have forgotten to check ?
> 
> Best regards,
> R?mi Lefevre

In real estate the three most important things are "location, location, 
location."  In engineering, they are "timing, timing, timing."

HTH,
gvb

[U-Boot] Malformed ARP packets

[Remi Lefevre]

Thank you very much for your clues as I'm stuck on this for almost a week.

[snip]
> Is this DIMM memory sticks with using SPD configuration or are the SDRAM
> chips soldered to the board?

They are soldered.

> Did you verify the SDRAM databook timing vs. what you configured your SDRAM
> controller to do?  Did the hardware engineer that made the board verify your
> configuration?  Did he give you a good configuration?  If so, are you sure
> it is good??? (never trust the hardware weenies ;-)
>
> Did you read and understand <http://www.denx.de/wiki/view/DULG/SDRAM> ?

My SDRAM is a Micron MT48LC16M16A2. My init sequence is exactly the same as
the one in "freescale/mpc8266ads/mpc8266ads.c" or "sacsng/sacsng.c" that use
MT48LC8M16A2 , but I checked it anyway.

My PSDMR values have been given by another product using exactly the same
board and same HWCR configuration (PLD). But I will check them again.

I think I may configure incorrectly some other register that disturbs
the timing.
I thought about ECC as they are used, and tried a configuration with
it disabled,
same result. I also disabled all caches (HID0) for precaution.
>
> In real estate the three most important things are "location, location,
> location."  In engineering, they are "timing, timing, timing."

I'm learning it the hard way (perhaps the only way...).

> HTH,
> gvb

Thanks,
R?mi

[U-Boot] Malformed ARP packets

[Jerry Van Baren]

Remi Lefevre wrote:
> Thank you very much for your clues as I'm stuck on this for almost a week.
> 
> [snip]
>> Is this DIMM memory sticks with using SPD configuration or are the SDRAM
>> chips soldered to the board?
> 
> They are soldered.

Yup, thought so. ;-)

> My SDRAM is a Micron MT48LC16M16A2. My init sequence is exactly the same as
> the one in "freescale/mpc8266ads/mpc8266ads.c" or "sacsng/sacsng.c" that use
> MT48LC8M16A2 , but I checked it anyway.

The SDRAM init sequence is odd, but hard to get wrong because it is 
invariant and there are plenty of working examples.

> My PSDMR values have been given by another product using exactly the same
> board and same HWCR configuration (PLD). But I will check them again.

That is the critical issue: the PSDMR values.  If all else fails, read 
the part number off a chip that is on your board and download the 
datasheet for *that* *exact* part number.  Sometimes manufacturers 
upgrade their parts or hardware makes a "compatible" substitution and 
the timing is different.

[snip]

> Thanks,
> R?mi

You are welcome,
gvb

[U-Boot] Malformed ARP packets

[Remi Lefevre]

> That is the critical issue: the PSDMR values.  If all else fails, read the
> part number off a chip that is on your board and download the datasheet for
> *that* *exact* part number.  Sometimes manufacturers upgrade their parts or
> hardware makes a "compatible" substitution and the timing is differ

I'm now angry to myself.
I was lost in refresh timers and memory controller settings and did not
check again the "so basic"  SDRAM device mode register.

Burst length was actually incorrect....  no comments!  I'm ashamed.

Thank you very much to have persuaded me it was a SDRAM issue, hope
was decreasing. And so sorry for wasted time...

Best regards,
R?mi

[U-Boot] Malformed ARP packets

[Jerry Van Baren]

Remi Lefevre wrote:
>> That is the critical issue: the PSDMR values.  If all else fails, read the
>> part number off a chip that is on your board and download the datasheet for
>> *that* *exact* part number.  Sometimes manufacturers upgrade their parts or
>> hardware makes a "compatible" substitution and the timing is differ
> 
> I'm now angry to myself.
> I was lost in refresh timers and memory controller settings and did not
> check again the "so basic"  SDRAM device mode register.
> 
> Burst length was actually incorrect....  no comments!  I'm ashamed.
> 
> Thank you very much to have persuaded me it was a SDRAM issue, hope
> was decreasing. And so sorry for wasted time...
> 
> Best regards,
> R?mi

Hi R?mi,

It is great that you have a solution and thanks for posting the 
resolution - all too many forget to do the last step of posting the 
resolution information.

Our "wasted time" will become the next engineer's 60 second problem 
identification and fix, due to the power of gmane/google *and* the fact 
that you posted the resolution.

For me, your SDRAM problem was not a waste of time, it was an intriguing 
puzzle to solve.  In the words of Sir Isaac Newton, a smoother pebble or 
a prettier shell.

"I know not what I appear to the world, but to myself I seem to have 
been only like a boy playing on the sea-shore, and diverting myself in 
now and then finding a smoother pebble or a prettier shell, whilest the 
great ocean of truth lay all undiscovered before me."

<http://www-groups.dcs.st-and.ac.uk/~history/Quotations/Newton.html>

gvb
(stepping down from the soapbox)