MCF5485, new Linux BSP, old u-boot -> mac address problem

[Nekto]

We faced problem with your M5485 Coldfire boards, u-boot and Linux BSP.

Initially we used m547x_8x_evb_20080811-final-ltib.iso BSP, u-boot 1.3.3 and our firmware and everything was ok. Then Freescale changed boards supply from REV:A and REV:B to REV:C and REV. Now we are receiving REV. Beginning with REV:C the u-boot from this BSP became incompatible with the boards. We made a transition of our project to new BSP CFLINUX_20100901_ltib.iso with u-boot 2009.08.
However, new BSP doesn’t look stable. Our firmware can run unpredictable period of time and system hangs up without any error messages. Further debugging is impossible. It may happen in dozens of minutes or after hours of run.
It was decided to roll back to previous BSP (m547x_8x_evb_20080811-final-ltib.iso). I flashed board (REV) with compatible new u-boot (2009.08), the BSP m547x_8x_evb_20080811-final-ltib.iso and our firmware. It works fine without hanging up. The only problem is mac address. During flashing the u-boot wiping out original mac address and we need to set ethaddr variable. Original u-boot doesn’t allow to do that. To overcome it I commented out this line:

#define CONFIG_OVERWRITE_ETHADDR_ONCE

in file /include/configs/M5485EVB.h.

Now I’m able to change the mac address in u-boot. However, when Linux is up and running, it still has wrong mac address.

I tried other way – to assign the mac address dynamically: ifconfig eth0 hw ether <macaddress>. This command doesn’t give any error, but the address is not changed. Further ifconfig call shows the same wrong address.

Can you help us to resolve the problem? Our system can’t run in the same network, because all of them have the same mac address.

[TomE]

This is a general observation about how U-Boot and Linux works. With luck you'll get someone responding who knows the proper solution to your problem.

U-Boot has the MAC accress in the Environment, or it can be coded to read it from somewhere else. It may write the MAC into the chip hardware as well.

When U-Boot runs Linux, it passes options to Linux using two different methods, and it passes the MAC over three possible ways. Options can be passed "on the command line" (what is in the "bootargs" U-Boot environment variable) or can be passed in the "Board Info" structure. The MAC can be passed "in the hardware", meaning that U-Boot writes it into the Ethernet controller registers, and Linux reads it back from there, usually as part of some code that looks for it there as well as in the other places.

The different versions of U-Boot and Linux may be disagreeing on the way.

Search for "bi_enetaddr" in all your u-boot sources to see how/if that is being loaded. Search for "bootargs" to see what's going in there. Read the Ethernet chip driver to see what it is doing. Search for "eth_set_enetaddr". You may have to revert to adding print statements to u-boot to see what it is doing and when.

Good luck.

Tom

[Nekto]

>U-Boot has the MAC accress in the Environment, or it can be coded to read it from somewhere else. It may write

> the MAC into the chip hardware as well.

How u-boot can write to the chip?

Thanks!

[TomE]

> How u-boot can write to the chip?

U-Boot can do anything it wants to.

U-Boot can usually be set up to load code over the network, so U-Boot usually has Ethernet driver code in it.

The MCF5485 has a "FEC" (Fast Ethernet Controller) module. Search the U-Boot source for code that writes to the "PALR" and "PAHR" registers.

I don't have your copy of U-Boot set up the way it is for you. I don't want a copy (don't post or send). Look in the U-Boot "cpu" directory. Find a directory in there that matches your chip. Look in there for a file called "fec.c' or a name close to that. Read it.

By mixing and matching you have a custom build that nobody else can support but you.

You should find out why the old one doesn't work on the new boards and change the old one so it works on all boards, or find out why the new one is unstable and fix it. Your mixed setup is unsupportable and can't be updated in the future.

What are the differences between Revs A, B and C? Have you looked for code or documentation on the differences? Have you compared the old and new u-Boot sources to see what changed? There may be a small bit of code in the new one that supports later revs you can copy into the older one.

> Further debugging is impossible.

Debugging is never impossible. There's always a way. It may take months of work, but it isn't "impossible". SIMPLIFY the system. Remove features and drivers until it is stable, then put them back until it fails. Remove your Application code. it may be triggering the problem.

If you don't want to read and understand the U-Boot and Linux code to find out what is wrong, you'll just have to wait and see if you get an answer here. If nobody else has your mixed setup, then there's nobody to help you anywhere.

There's another problem. A particular version of U-Boot sets up the hardware (writes to controller registers0 for the version of Linux.it was shipped with.There may be parts that have to match between them, and the old and new ones ARE different because the MAC-address setting isn't working when you mix and match. There may be other ptoblems you haven't noticed yet.

That's why your "new u-boot and old linux" is a bad idea.

Tom