beagleboard unique identifier

Hello, I need to get a unique identifier for each Beagleboard in order to automate installations, I’ve seen in u-boot there is a “Die ID”, but with /proc/cpuinfo I get the Serial number empty.
Is the “Die ID” really a unique identifier or it only differentiates from one revision to another?
Is there anyway to retrieve a unique identifier from userspace?


What about the MAC address?

Hello, I need to get a unique identifier for each Beagleboard in order to automate installations, I’ve seen in u-boot there is a “Die ID”, but with /proc/cpuinfo I get the Serial number empty.

You're assuming that there is an ethernet adapter attached. :slight_smile:

What if this is some sort of installation via MMC card?

I don't think the kernel even reads the Die ID on OMAP3 (yes, it's unique). This might help:

Steve wrote:

There is a patch for it, though.

Pawel Potera wrote:

Thank’s Pawel, you are right, I don’t wan’t to assume I have an ethernet connected.
Sorry but I’m not very familiar with kernel and sysfs, I’m currently using angstrom-distribution with kernel 2.6.29-r48, I’ve located id.c under the kernel sources but I don’t know if its defined in the defconfig file, I can’t find the option from reading the id.c file. I also don’t know if I need the patch or not.
And if I have already built into the kernel I can’t find it under /sys

Could you tell me what to look for?


Can you try the following and see what happens?

mount -t sysfs sysfs /sys

Then look in /sys.

id.c is definitely compiled into your kernel.

Marc wrote:

I think I misread your email. I though you somehow didn't have /sys. If you do have the patch applied and you recompile the kernel, you should be able to look in /sys/power for the die ID.

Pawel Potera wrote:

Each OMAP has a unique 128 bit ID. The following code will print it out.

#define CONTROL_ID_CODE_ADDR 0x4830A204 //VERSION Bits [31:28], HAWKEYE
Bits [27:12] (Silicon Type)

#define CONTROL_DIE_ID_0 0x4830A218

#define CONTROL_DIE_ID_1 0x4830A21C

#define CONTROL_DIE_ID_2 0x4830A220

#define CONTROL_DIE_ID_3 0x4830A224

            unsigned int regVal0, regVal1, regVal2, regVal3;

             regVal0 = *(unsigned int*)CONTROL_ID_CODE_ADDR;

             serial_printf("VERSION %x\r\n",0xf&(regVal0>>28));

            serial_printf("HAWKEYE %x\r\n",0xffff&(regVal0>>12));

//Print out the unique 128 bit ID for this CPU

            regVal3 = *(unsigned int*)CONTROL_DIE_ID_3;

            regVal2 = *(unsigned int*)CONTROL_DIE_ID_2;

            regVal1 = *(unsigned int*)CONTROL_DIE_ID_1;

            regVal0 = *(unsigned int*)CONTROL_DIE_ID_0;

            serial_printf("Serial #


Brad Badke

Hemisphere GPS

8444 N 90th St #130

Scottsdale, AZ 85258

Direct: 480-348-6323

Fax: 480-348-6370 <> <>

Sorry Brad, isn’t this code for u-boot?
Can I make a simple C program and run it to get the ID from userspace?
isn’t serial_printf a function to print out serial port?

As you see I have way to many questions :slight_smile:

And following the thread I also have another question for Pawel, I didn’t apply the patch but It looks like the code is already in id.c under the kernel tree, what I don’t know is which option I have to select when I compile it.
Under /sys/power I only have:

Thank you both.

This patch works for me on the 2.6.31 kernel with power management enabled

$ cat /sys/power/idcode # numbers changed to protect the guilty
IDCODE: deadbeef
Production ID: 00000000 00000003 000000f0 deadbeef
Die ID: cafefeed cafebeef 00000000 deadbeef


There is similar code, but not the magic sysfs_create_file part. Try applying
the patch and rebuild. It worked for me. I now have a /sys/power/idcode file,
filled with id information.


Hello again, It’s been a while but I finally had time to try this.
The patch works fine and now I get the file /sys/power/idcode

This file has

IDCODE: 3b7ae02f
Production ID: 00000000 00000003 000000f0 cafeb7ae
Die ID: 0e01801f 04032309 00000000 0eca0003

which is simmilar to the Die ID that outputs before it enters uboot (its actually the same whith some bytes in different order)

Is there any relation between any of this numbers and the serial ID printed on the board? I’ve tryied many combinations with mine but they seem unrelated.

There is no relation whatsoever.