[U-Boot-Users] 855T FEC error
Dear all,
We have u-boot (1.0.0) running on our custom board :)
Our board uses 855T and LXT972A.
Trying to do:
ACM=> bootp Trying FEC ETHERNET PHY type 0x13 pass 1 type PHY @ 0x0 pass 1 type LXT971 BOOTP broadcast 1 TX timeout fec.c[134] fec_send: cycles: 100 status: 8c00 retry cnt: 0
With a login analyzer we can see that after some time the TX_ER is raised and TX_EN not.
The PHY seem to work OK. The LED's light correctly and we can see the 25MHz TX and TX MII clocks.
Reading the registers with u-boot's mii read, the registers are the same as the TQM860L.
We use the same configuration as TQM855L.h, but we add - CONFIG_8xx_GCLK_FREQ 50000000.
I don't think its related to this problem, but we cannot save the u-boot environment. It is saved to the flash at 4000c000 but does not appear after reset following printenv. I didn't have time to look into this issue yes.
Last but not least, I wish to thank you all, the information in this list helped us very much.
Any suggestions ?
Thank you, Eli Brin
Dear Eli,
in message C32B9C30CA0FD81189CF0008024506EE017FEA@ROKMAIL you wrote:
Trying FEC ETHERNET PHY type 0x13 pass 1 type PHY @ 0x0 pass 1 type LXT971 BOOTP broadcast 1 TX timeout fec.c[134] fec_send: cycles: 100 status: 8c00 retry cnt: 0
...
Reading the registers with u-boot's mii read, the registers are the same as the TQM860L.
We use the same configuration as TQM855L.h, but we add -
Do you also use exactly the same clock routing?
My first guess is that you misconfigured the clocks.
I don't think its related to this problem, but we cannot save the u-boot environment. It is saved to the flash at 4000c000 but does not appear after reset following printenv. I didn't have time to look into this issue yes.
You probably have different flash chips so you need to adjust the flash driver, environment location and linker map?
Best regards,
Wolfgang Denk
Eli Brin writes:
...
Eli> I don't think its related to this problem, but we cannot save Eli> the u-boot environment. It is saved to the flash at 4000c000 Eli> but does not appear after reset following printenv. I didn't Eli> have time to look into this issue yes.
...
It looks like the old problem which appeared first in MPC8xxADS family port and was discussed on this list in June. It was mentioned again several days ago and the consensus was that it was solved long time ago but I had the same problem today on MPC866ADS (and I use the latest U-Boot sources.) Anyway, look at the CFG_MONITOR_LEN define in your board configuration file. If it includes the environment (i.e. you're using "embedded environment") this is most probably the problem. I changed CFG_MONITOR_LEN on my board so that (CFG_MONITOR_BASE + CFG_MONITOR_LEN) does not include the environment and the problem disappeared.
In message 16313.1494.55833.465590@gargle.gargle.HOWL you wrote:
It looks like the old problem which appeared first in MPC8xxADS family port and was discussed on this list in June. It was mentioned again several days ago and the consensus was that it was solved long time ago but I had the same problem today on MPC866ADS (and I use the latest U-Boot sources.) Anyway, look at the CFG_MONITOR_LEN define in your board configuration file. If it includes the environment (i.e. you're using "embedded environment") this is most probably the problem. I
Yuli, please stop spreading FUD!
Your statement is bogus.
We use embedded flash environments on nearly all of our boards without any problems.
Of course you have to get the configuration right, i. e. the environment address as defined in the board config file must match the flash chip's sector layout, and your linker script must match that, too.
Best regards,
Wolfgang Denk
participants (3)
-
Eli Brin -
Wolfgang Denk -
Yuli Barcohen