[U-Boot] what's the uboot way to pass eth*addr to linux ?
Hello
I have a problem : my (coldfire) linux kernel does not reuse the mac addresses known by u-boot as ethaddr and eth1addr.
I have read doc/README.enetaddr, that states :
struct bd_info [...] are temporary copies of the MAC address only for the purpose of passing this information to an OS kernel we are about to boot.
but I see no field in bd_info that could be set before booting linux.
I thought that the address of the environment zone could be given to linux, but I do not see where either.
So what's the recommended/supported way to inform the kernel of the mac addresses of all the ethernet interfaces ?
Philippe
Hi Philippe!
May be it is a little bit tricky but you can just read the u-boot environment from you Linux driver and use the "ethaddr" variable. I did the same for osk5912
2010/2/19 Philippe De Muyter phdm@macqel.be
Hello
I have a problem : my (coldfire) linux kernel does not reuse the mac addresses known by u-boot as ethaddr and eth1addr.
I have read doc/README.enetaddr, that states :
struct bd_info [...] are temporary copies of the MAC address only for the purpose of passing this information to an OS kernel we are about to boot.but I see no field in bd_info that could be set before booting linux.
I thought that the address of the environment zone could be given to linux, but I do not see where either.
So what's the recommended/supported way to inform the kernel of the mac addresses of all the ethernet interfaces ?
Philippe _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi Maxim,
On Sat, Feb 20, 2010 at 10:30:32AM +0300, Maxim Podbereznyi wrote:
Hi Philippe!
May be it is a little bit tricky but you can just read the u-boot environment from you Linux driver and use the "ethaddr" variable. I did the same for osk5912
Thanks, but I need something more straightforward. The ethernet driver in linux must know the mac address at startup to be able to have root on nfs.
Previously, the mac addresses were stored in the bd_info struct, but that has been removed, but alas not replaced by a common mechanism for all architectures.
Philippe
Dear Philippe De Muyter,
In message 20100220093717.GA9602@frolo.macqel you wrote:
Previously, the mac addresses were stored in the bd_info struct, but that has been removed, but alas not replaced by a common mechanism for all architectures.
Complain about this to the Linux architecture maintainers - there have been many and longf discussions about this before.
Today we consider the device tree to be the Right Thing (TM) to pass such information to the kernel, and more and more architectures use this method.
As long as it's not available for your architecture, the most straightforward way is to pass an "ethaddr=..." argument on the kernel command line. Drivers can pick it up easily there. Just don't expect that such Linux driver code will be accepted for mainline.
Hello Wolfgang,
On Sat, Feb 20, 2010 at 04:08:45PM +0100, Wolfgang Denk wrote:
Dear Philippe De Muyter,
In message 20100220093717.GA9602@frolo.macqel you wrote:
Previously, the mac addresses were stored in the bd_info struct, but that has been removed, but alas not replaced by a common mechanism for all architectures.
Complain about this to the Linux architecture maintainers - there have been many and longf discussions about this before.
Do you mean lkml or some other mailing list or individual ?
Today we consider the device tree to be the Right Thing (TM) to pass such information to the kernel, and more and more architectures use this method.
AFAIK, device trees are powerpc-specific and my board is coldfire based.
As long as it's not available for your architecture, the most straightforward way is to pass an "ethaddr=..." argument on the kernel command line. Drivers can pick it up easily there. Just don't expect that such Linux driver code will be accepted for mainline.
I don't like that method because it can easily be forgotten by someone changing bootargs for some other reason. IMO bootargs should only be used for configuration choices.
I'd rather go for an additional parameter given by u-boot to linux with the address of the used u-boot environment, passed the same way that the address of bd_info is given to linux (for coldfire's, that's on the stack)
Philippe
Dear Philippe De Muyter,
In message 20100220235945.GA15901@frolo.macqel you wrote:
Complain about this to the Linux architecture maintainers - there have been many and longf discussions about this before.
Do you mean lkml or some other mailing list or individual ?
I had especially the ARM list and RMK in mind.
Today we consider the device tree to be the Right Thing (TM) to pass such information to the kernel, and more and more architectures use this method.
AFAIK, device trees are powerpc-specific and my board is coldfire based.
Several other architecture use the device tree as well, and more are following. For example, an adaption for ARM is on the way right now.
As long as it's not available for your architecture, the most straightforward way is to pass an "ethaddr=..." argument on the kernel command line. Drivers can pick it up easily there. Just don't expect that such Linux driver code will be accepted for mainline.
I don't like that method because it can easily be forgotten by someone changing bootargs for some other reason. IMO bootargs should only be used for configuration choices.
Well, that's mostly a matter of taste. At least it's an architecutre independent, standardized way to pass information.
I'd rather go for an additional parameter given by u-boot to linux with the address of the used u-boot environment, passed the same way that the address of bd_info is given to linux (for coldfire's, that's on the stack)
i. e. you create yet another, non-standard solution - exactly what you complained about originally.
Best regards,
Wolfgang Denk
On Saturday 20 February 2010 04:37:17 Philippe De Muyter wrote:
On Sat, Feb 20, 2010 at 10:30:32AM +0300, Maxim Podbereznyi wrote:
Hi Philippe!
May be it is a little bit tricky but you can just read the u-boot environment from you Linux driver and use the "ethaddr" variable. I did the same for osk5912
Thanks, but I need something more straightforward. The ethernet driver in linux must know the mac address at startup to be able to have root on nfs.
a small static initramfs would take care of this just fine -mike
Hi Maxim,
On Sat, Feb 20, 2010 at 10:30:32AM +0300, Maxim Podbereznyi wrote:
Hi Philippe!
May be it is a little bit tricky but you can just read the u-boot environment from you Linux driver and use the "ethaddr" variable. I did the same for osk5912
Sorry, I replied too fast, It seems that I misunderstood your answer. How do you access the U-boot environment from the linux driver ? Is there a linux kernel library function to retrieve one element of a U-boot environment ? Does U-boot tell linux where the U-boot environment resides in memory ?
Philippe
Hi!
Well, I know nothing about coldfire but for osk5912 it is well known where all partitions reside on the flash. You can find it the u-boot config file for coldfire.
The code for MontaVista with kernel 2.4:
static int nicGetMacAddress(u8* macaddr) { int ret = 0;
if (check_mem_region(FLASH_PARAM_ ADDR, FLASH_PARAM_SIZE)) { printk("enc28j60: flash memory already in use\n"); return ENXIO; } else { unsigned long base = FLASH_PARAM_ADDR; unsigned long size = FLASH_PARAM_SIZE; void *vbase; unsigned char *sf = NULL; int res; int i; char *endptr;
res = request_mem_region(base, size, "enc28j60-flash"); if (!res) { printk("enc28j60: flash memory mapping failed\n"); return ENXIO; } vbase = ioremap(base, size); if (!vbase) { printk("enc28j60: flash memory ioremap failed\n"); return ENOMEM; } sf = (char *)vbase;
endptr = fw_getenv(sf, "ethaddr"); if (endptr) for (i=0; i<6; i++) { // IPv4 unsigned long tmp; char *str = endptr+1; tmp = enc28_strtoul(str, &endptr, 16); *macaddr++ = tmp; } else { printk("enc28j60: no ethaddr variable in u-boot environment"); ret = EINVAL; }
iounmap(vbase); release_resource(res); }
return ret; }
Hope you can easily adapt it to your kernel!
2010/2/20 Philippe De Muyter phdm@macqel.be
Hi Maxim,
On Sat, Feb 20, 2010 at 10:30:32AM +0300, Maxim Podbereznyi wrote:
Hi Philippe!
May be it is a little bit tricky but you can just read the u-boot environment from you Linux driver and use the "ethaddr" variable. I did
the
same for osk5912
Sorry, I replied too fast, It seems that I misunderstood your answer. How do you access the U-boot environment from the linux driver ? Is there a linux kernel library function to retrieve one element of a U-boot environment ? Does U-boot tell linux where the U-boot environment resides in memory ?
Philippe
Hi Maxim,
On Sat, Feb 20, 2010 at 05:49:53PM +0300, Maxim Podbereznyi wrote:
The code for MontaVista with kernel 2.4:
static int nicGetMacAddress(u8* macaddr) {
[...]
endptr = fw_getenv(sf, "ethaddr");
[...]
}
Hope you can easily adapt it to your kernel!
So the library fucntion to retrieve the value of a u-boot environment variable is 'fw_getenv'. I do not have that function in my linux sources.
Philippe
Hi Philippe,
On Sat, Feb 20, 2010 at 4:47 PM, Philippe De Muyter phdm@macqel.be wrote:
Hi Maxim,
On Sat, Feb 20, 2010 at 05:49:53PM +0300, Maxim Podbereznyi wrote:
The code for MontaVista with kernel 2.4:
static int nicGetMacAddress(u8* macaddr) {
[...]
endptr = fw_getenv(sf, "ethaddr");[...]
}
Hope you can easily adapt it to your kernel!
So the library fucntion to retrieve the value of a u-boot environment variable is 'fw_getenv'. I do not have that function in my linux sources.
It's a tool in the U-boot source tree.
Philippe
regards, Ben
Dear Philippe De Muyter,
In message 20100221004733.GA22011@frolo.macqel you wrote:
Hope you can easily adapt it to your kernel!
So the library fucntion to retrieve the value of a u-boot environment variable is 'fw_getenv'. I do not have that function in my linux sources.
Did I not already point you to tools/env/* ?
Best regards,
Wolfgang Denk
participants (5)
-
Ben Warren -
Maxim Podbereznyi -
Mike Frysinger -
Philippe De Muyter -
Wolfgang Denk