mips: When booting Linux images, add 'ethaddr' and 'eth1addr' to the environment

Add 'ethaddr' and 'eth1addr' to the Linux kernel environment if they are set in the U-Boot environment.

---
 lib_mips/bootm.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

index f813fc5..8fe3782 100644
@@ -54,6 +54,7 @@ void do_bootm_linux (cmd_tbl_t * cmdtp, int flag, int argc, char *argv[],
 	char	*commandline = getenv ("bootargs");
 	char	env_buf[12];
 	int	ret;
+	const char *cp;
 
 	/* find kernel entry point */
 	if (images->legacy_hdr_valid) {

@@ -113,6 +114,16 @@ void do_bootm_linux (cmd_tbl_t * cmdtp, int flag, int argc, char *argv[],
 	sprintf (env_buf, "0x%X", (uint) (gd->bd->bi_flashsize));
 	linux_env_set ("flash_size", env_buf);
 
+	cp = getenv("ethaddr");
+	if (cp != NULL) {
+		linux_env_set("ethaddr", cp);
+	}
+
+	cp = getenv("eth1addr");
+	if (cp != NULL) {
+		linux_env_set("eth1addr", cp);
+	}
+
 	if (!images->autostart)
 		return ;
 

1.5.4.3

I missed this mail, sorry for my late reply.

Patch itself looks correct, but let me confirm.

Looking closely into linux/arch/*, I found that mips is the only architecture which supports the 'ethaddr' kernel parameter. Is this right? What I want to make sure is whether 'ethaddr' is an unusual kernel parameter or not.

I think it's possible to probe MAC address(es) on kernel side, and it's common practice IMO. [ if not so, Linux couldn't work without suitable bootldrs which can pass the 'ethaddr' parameter. It's inconvenient, at least for me. ]

However, I don't have strong opinions on this matter. If you still have troubles without this change, or can't probe MAC addresses by Kernel due to some reason, I'll apply the patch.

Comments?

Shinya

On our devices, the U-Boot environment is the only place the ethernet MAC address is stored.

Since the infrastructure for passing environment variables up to the MIPS Linux kernel existed anyways, I decided that it would be a better plan to use that machanism than to have the kernel dig through the duplicate U-Boot environments.

I don't consider this patch a "must have" for upstream. I try to make sure all the changes that are needed for our product are sent to the u-boot list, even if they don't end up being accepted for DENX's U-Boot.

On a completely unrelated topic, I really like the MIPS 'environment' method of passing information to the kernel instead of the old 'bd_t' method. It's a lot more flexible.

Jason McMullan
MTS SW
System Firmware

NetApp

724.741.5011    Fax
724.741.5166    Direct
412.656.3519    Mobile

jason.mcmullan at netapp.com
www.netapp.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080707/5b77ccfe/attachment.pgp

Thanks for the explanations. As Linux/MIPS kernel supports this parameter anyway, it's good for U-Boot to support that, too.

Applied, will send to Wolfgang asap.

Shinya