BeagleBoard Unique ID?

Hi all,
I'm trying to work out if the BeagleBoard has some form of unique (and
ideally, secure) id?

This thread suggests that something is available in a particular
register:
http://groups.google.com/group/beagleboard/browse_frm/thread/7d1719a7866a6bc8/d45669c9e98eecb8?lnk=gst&q=secure+mode#d45669c9e98eecb8
But is not really accessible.

Is there anything else available?

Thanks!

-Richard

Hello,

I am trying to invalidate the I-cache using the following in my code:

asm(" MCR p15, 0, r0, c7, c5, 0");

I am able to compile successfully. However, when I try to execute the code, I get an “Illegal Instruction” output.

Does this mean that the kernel I am using is not supporting the MCR instruction? If yes, what should be the selection in menuconfig?

Thanks in advance,

Krishna

This means this instruction is privileged and can only be run by the kernel.
This behaviour is documented here:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344b/Babhejba.html

ARM Linux kernel has a syscall to flush caches. I don't know how to
invoke it, but google should be your friend :slight_smile: Look for arm and
cacheflush.

Laurent

Hi Richard,

You can use the DIE_ID-register which will be unique for each OMAP-chip:
   CONTROL.CONTROL_DIE_ID[127:0] 0x4830A218

The register is build internally at TI during production, and contains
unique info for each device... Unfortunately I haven't found the format
officially available to TI externals, which is the reason I don't disclose
more information here - But trust me it's unique... :slight_smile:

The officially released info can be found at page 195 in the TRM :slight_smile:

Best regards - Good luck
  Søren

PS: What do you mean with "secure" on a GP device?
The DIE_IUD is fused into the chip, and can't be changed - Is this what you
meant?

Hi Soeren,
that sounds like exactly what I need; an id that's unique to the
device and can't be (easily) changed or 'spoofed'.

Shame there's no way of getting to it...
What is the TRM document that you referred to?

Thanks!
-Richard

That is the Tecnical Reference Manual. It is the bible for the OMAP3530. You can find it at http://focus.ti.com/docs/prod/folders/print/omap3530.html

Gerald

Hi Richard,

The document is called spruf98b.pdf - See as well the link just send by
Gerald...

that sounds like exactly what I need; an id that's unique to the
device and can't be (easily) changed or 'spoofed'.

Agree - Both properties are valid for DIE_ID...

Shame there's no way of getting to it...

No way of getting to it? Do you mean you have problems reading it in SW?
Or the fact, that the information isn't fully public?
  Søren

Hi Richard,

You can use the DIE_ID-register which will be unique for each OMAP-chip:
CONTROL.CONTROL_DIE_ID[127:0] 0x4830A218

The register is build internally at TI during production, and contains
unique info for each device... Unfortunately I haven't found the format
officially available to TI externals, which is the reason I don't disclose
more information here - But trust me it's unique... :slight_smile:

The officially released info can be found at page 195 in the TRM :slight_smile:

Best regards - Good luck
Søren

PS: What do you mean with "secure" on a GP device?
The DIE_IUD is fused into the chip, and can't be changed - Is this what

you

meant?

> Hi all,
> I'm trying to work out if the BeagleBoard has some form of unique (and
> ideally, secure) id?

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.10.9/1900 - Release Date: 19-01-2009
09:37

Have you been successful in reading this register?

My experience is that this register cannot be accessed unless you are
running in secure mode.

If you have found a way, please share!

Steve

Hi Richard,

You can use the DIE_ID-register which will be unique for each OMAP-chip:
  CONTROL.CONTROL_DIE_ID[127:0] 0x4830A218

Have you been successful in reading this register?

My experience is that this register cannot be accessed unless you are
running in secure mode.

If you have found a way, please share!

Steve

This register as well? In given case, I find it strange - Normally the
DIE_ID is fine accessible in a GP-device, but to be honest I haven't checked
it on the OMAP3530 - At least not for a while - I can't remember if ever? I
however checked it on an OMAPv1035 GP-device not that long ago - Here it's
working. :slight_smile:

I will give it at try ASAP - Probably sometime tonight EU time?
  Søren

Hi Richard,

You can use the DIE_ID-register which will be unique for each OMAP-chip:
  CONTROL.CONTROL_DIE_ID[127:0] 0x4830A218

Have you been successful in reading this register?

My experience is that this register cannot be accessed unless you are
running in secure mode.

If you have found a way, please share!

Steve

This register as well? In given case, I find it strange - Normally the
DIE_ID is fine accessible in a GP-device, but to be honest I haven't

checked

it on the OMAP3530 - At least not for a while - I can't remember if ever? I
however checked it on an OMAPv1035 GP-device not that long ago - Here it's
working. :slight_smile:

I will give it at try ASAP - Probably sometime tonight EU time?
Søren

I just gave it a quick try in u-boot with the md (memory display) command,
which worked fine...
- At least the board didn't crash and AFAIR the value looks OK as well.

OMAP3 beagleboard.org # md 0x4830a218 1
4830a218: 0a018019 ....
OMAP3 beagleboard.org #

Best regards
  Søren

Thanks Soeren,
that looks good.

I'm going to save time and admit my ignorance; how would I go about
accessing this register in my C code running on the board? I.e. do
you have a little code snippet you could share?

Thanks very much in advance,

-Richard

I cant give you a code snippet, but the register lies at a physical
address, and your application runs in the virtual address space. The
standard way to cross the barrier is with a kernel driver. Look for
information about kernel drivers on the net you will see examples of the
sort of code you need.

Strontium

Richard wrote:

OK, so I'm replying to my own message... :slight_smile:

Many thanks to 'mru' for a great example on how to achieve this:
http://thrashbarg.mansr.com/~mru/memdump.c

The key point is to use mmap to read the appropriate bytes from /dev/
mem

-Richard