[U-Boot] Generating random numbers
Hi,
I am trying to random my mac in u-boot on AT91RM9200 and AT91SAM9G45 processor. My purpose is that before a MAC is assigned to the board at production, the board should use a random MAC address (and random IP) and also that it shouldn't conflict with other devices on the same network.
In lib_arm/board.c if the environment variables ethaddr and ipaddr are not set, I generate a random MAC and IP.
bootcmd is set to tftp "filename";autoscr $(TFTP_LOAD_ADDR) in the config.h file. A tftp server on the network reads the filename(different for different products) and calls mkimage to create a u-boot script file that sets the correct MAC address and the correct bootcmd after getting one from the database. This is to reduce the time at Production. At present they have to connect each board's serial cable and set the MAC address.
On the 9G45, I used the pseudo-random generator from board/esd/du440/du440.c along with a few combinations of udelay and get_timer and am able to get different MAC addresses over reboots and also different MAC addresses on similar boards.
start_time=get_timer(0); udelay(start_time); prng(start_time); elapsed_time=get_timer(start_time); udelay(elapsed_time); etc along with a few more loops.
However the same code generates the same sequence of random numbers on the AT91RM9200. I am not sure how this code generates different numbers every time on the AT91SAM9G45 !
On the AT91RM9200, I also tried using bfin_gen_rand_mac from arch/blackfin/include/asm/net.h, However I always get the same sequence of random numbers.
/* make something up */ const char s[] = __DATE__; size_t i; u32 cycles; for (i = 0; i < 6; ++i) { asm("%0 = CYCLES;" : "=r" (cycles)); mac_addr[i] = cycles ^ s[i]; } mac_addr[0] = (mac_addr[0] | 0x02) & ~0x01; /* make it local unicast */
Is there any method to generate different sequences of random numbers by the same code executing on same machines? I could do this after the kernel starts using /dev/urandom and then use fw_setenv but I prefer to do it in U-boot.
Does using fw_setenv require the flash partition containing the U-boot environment variables be mounted as read-write? Because I mount it as read-only.
Thanks, Elison
Dear "elison.niven@gmail.com",
In message CAAO=tyeYTt4M+54y_qovCK7vdQy_ssOktRdjbPF8+Pq0-YcCzQ@mail.gmail.com you wrote:
I am trying to random my mac in u-boot on AT91RM9200 and AT91SAM9G45 processor.
This approach is inherently wrong, and I'm actually happy if you find it difficult to implement. Otherwise we would probably have rejected your code when you submit the patches.
MAC addresses are supposed to be NOT random. Please see the related FAQ, for example http://www.denx.de/wiki/view/DULG/WhereCanIGetAValidMACAddress
Best regards,
Wolfgang Denk
On Wed, Aug 31, 2011 at 1:25 AM, Wolfgang Denk wd@denx.de wrote:
Dear "elison.niven@gmail.com",
In message <CAAO= tyeYTt4M+54y_qovCK7vdQy_ssOktRdjbPF8+Pq0-YcCzQ@mail.gmail.com> you wrote:
I am trying to random my mac in u-boot on AT91RM9200 and AT91SAM9G45 processor.
This approach is inherently wrong, and I'm actually happy if you find it difficult to implement. Otherwise we would probably have rejected your code when you submit the patches.
MAC addresses are supposed to be NOT random. Please see the related FAQ, for example http://www.denx.de/wiki/view/DULG/WhereCanIGetAValidMACAddress
Hi,
I do realize that. The "random" MAC address is not forever. It is only to get the "actual" MAC in the first boot so as to not set the environment variables manually.
Thanks, Elison
Le 30/08/2011 22:10, elison.niven@gmail.com a écrit :
On Wed, Aug 31, 2011 at 1:25 AM, Wolfgang Denkwd@denx.de wrote:
Dear "elison.niven@gmail.com",
In message<CAAO= tyeYTt4M+54y_qovCK7vdQy_ssOktRdjbPF8+Pq0-YcCzQ@mail.gmail.com> you wrote:
I am trying to random my mac in u-boot on AT91RM9200 and AT91SAM9G45 processor.
This approach is inherently wrong, and I'm actually happy if you find it difficult to implement. Otherwise we would probably have rejected your code when you submit the patches.
MAC addresses are supposed to be NOT random. Please see the related FAQ, for example http://www.denx.de/wiki/view/DULG/WhereCanIGetAValidMACAddress
Hi,
I do realize that. The "random" MAC address is not forever. It is only to get the "actual" MAC in the first boot so as to not set the environment variables manually.
If it is only until the environment provides the MAC, then I suspect the "random MAC" will never ever be used in a single packet, right? But then, what's the point of setting it if it won't be used at all? Simply set the real MAC once you have it.
(from your other reply)
Why does arch/blackfin/include/asm/net.h have bfin_gen_rand_mac ?
Just because some code in U-Boot appears to wrongly use random MACs does not *make* it wrong, and does not make the use you intend right either.. :)
In the Blackfin case, just as in the the Marvell GBE driver case, a random MAC is generated only if the actual MAC is *not* in the environment -- a case that should not happen in normal cicumstances.
The blackfin use case is "if the environment does not contain a MAC, then as a degenerate case we provide a private (random) MAC so that the U-Boot can still use the network" -- a resilience case for a degenerate situation.
This differs from your use case which apparently is "use a random MAC so that with some yet-undefined mechanism we can ask for a real MAC because we don't want to set the real MAC in the environment" -- to me it looks not like a degenerate case but a nominal use case.
Now I may have misunderstood your case, of course. Feel free to provide more context.
Amicalement,
On Wed, Aug 31, 2011 at 1:25 AM, Wolfgang Denk wd@denx.de wrote:
This approach is inherently wrong, and I'm actually happy if you
find it difficult to implement. Otherwise we would probably have rejected your code when you submit the patches.
Why does arch/blackfin/include/asm/net.h have bfin_gen_rand_mac ?
Thanks, Elison
Tue Aug 30 23:48:41, Albert ARIBAUD albert.u.boot at aribaud.net wrote:
This differs from your use case which apparently is "use a random MAC so that with some yet-undefined mechanism we can ask for a real MAC because we don't want to set the real MAC in the environment" -- to me it looks not like a degenerate case but a nominal use case.
How am I supposed to set the real MAC in the environment? Build separate images for each board? I do not want that.
Now I may have misunderstood your case, of course. Feel free to provide more context.
I think I have pretty much summarized it in the first mail of this thread.
Thanks, Elison
Dear "elison.niven@gmail.com",
In message CAAO=tycSJgHWdUvYrH5zecHM6L6F4KPeC8qyu8_PzZaCibN7Bw@mail.gmail.com you wrote:
How am I supposed to set the real MAC in the environment? Build separate images for each board? I do not want that.
Not that is finally a good question, and one where answering makes sense again.
There are many ways, depending on how you organized the production and/or testing of your boards.
If either of these steps includes to actually boot up U-Boot (for example, to run some production test software etc.), then it is usually tricial to use plain standard "env set" + "env save" commands to set and store the MAC address - and probably the serial number and/or other vital product data as well.
If you use any specific means to set the serial number of your board (for example, but using a Silicon Serial Number chip or similar, you should define a method to derive the MAC address from the serial number.
If you are doing none of these, you may find other ways to write a small block with the respective information into flash during your hardware tests. This is done on a number of boards. See for example function load_sernum_ethaddr() in "board/tqc/tqm8xx/load_sernum_ethaddr.c"; in this case, a small block of data gets written into a predefined location of the NOR flash during the functional test of these boards, using directly the PCB test probe.
If you are capable of booting from SDCard, it may be sufficient to generate respective files (with the environment data) on your SDcards that get loaded automatically at first boot (for example by using PREBOOT settings; such a command can even delete itself from the environment when done, so this is allows for one-time actions.
Of course, you can also pre-program your flashes before even fitting the chips on the boards. There are programmers that support auto- incrementing serial numbers or automatic insertion of data blocks retrieved from some sort of production database.
etc. etc.
There is a zillion of methods to do what you want, you just have to pick one that fits your board and your productions and test environment best. And any of these is way better than using random MAC addresses.
Best regards,
Wolfgang Denk
some Blackfin boards use the flash method Wolfgang mentioned: the last sector of flash has the MAC address programmed into it at the factory
other boards have the MAC burned into OTP that is inside the processor ... again, done at the factory -mike
On Thu, Sep 1, 2011 at 12:45 AM, Wolfgang Denk wd@denx.de wrote:
Dear "elison.niven@gmail.com",
In message CAAO=tycSJgHWdUvYrH5zecHM6L6F4KPeC8qyu8_PzZaCibN7Bw@mail.gmail.com you wrote:
How am I supposed to set the real MAC in the environment? Build separate images for each board? I do not want that.
Not that is finally a good question, and one where answering makes sense again.
There are many ways, depending on how you organized the production and/or testing of your boards.
Of course, you can also pre-program your flashes before even fitting the chips on the boards. There are programmers that support auto- incrementing serial numbers or automatic insertion of data blocks retrieved from some sort of production database.
Yes, this is what I am looking into. Seems the most fitting in my case.
There is a zillion of methods to do what you want, you just have to pick one that fits your board and your productions and test environment best. And any of these is way better than using random MAC addresses.
Thanks a lot !
Thanks, Elison
participants (4)
-
Albert ARIBAUD -
elison.niven＠gmail.com -
Mike Frysinger -
Wolfgang Denk