[U-Boot] Malformed ARP packets
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
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
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
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
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
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)
participants (3)
-
Jerry Van Baren -
Jerry Van Baren -
Remi Lefevre