Decoding the RPi serial number

Hi everyone,
Can someone from the foundation please tell us the serial number encoding scheme ?

Surely it's not incremental - even if the first 10 RPis that were sold on the eBay had a low serial number, my 2nd pi has 000000004db34690 - that's "1303594640" in decimal and there's no way that many have been made.
So some of the bits in there mean something like year+batch number and/or manufacturer.

Thanks.

EDIT: Why this would matter ? I presume that when Farnell & RS will start mass production of their boards, they may not use the same colour for the PCB or the same colour for connectors.
So an introductory software (for the children) presenting the layout of their Pi will be able to tell them:
"Observe the blue PCB. The red connector on the upper side is the composite video and the green connector next to it is for headphones" based on the data decoded from the serial number.

The presence of a "program_serial_random" option in start.elf suggests that the serial numbers are just random, or possibly pseudo-random. (Fun fact: if they were truly random and uniform, then if you bought 4823 pies there is 50% chance that two would have the same ethernet MAC address.)

So an introductory software (for the children) presenting the layout of their Pi will be able to tell them: "Observe the blue PCB. The red connector on the upper side is the composite video and the green connector next to it is for headphones" based on the data decoded from the serial number.

Nearly all the cables will need to be in place before any software can be run. And none of them will fit correctly in the wrong holes. And the obvious solution is to show a picture instead of trying to describe by colour alone.

The presence of a "program_serial_random" option in start.elf

Hadn't heard of that one before, so did some searching and found viewtopic.php?f=28&t=5486 which suggests the serial numbers are random. Curiouser and curiouser...

I presume that when Farnell & RS will start mass production of their boards...

I thought they already had started mass-production. viewtopic.php?f=63&t=5889

I tested a friends fresh out of the box RPi wiith my sdcard at work a couple days ago. When I tried to ssh into it my PC detected that my friends RPi was not the one that last made the ssh connection. So there must be a hardware number in there else he's RPi would have shown the same number as mine. Maybe it's set the first time the RPi is run???

Just for reference about SSH. The ssh server doesn't use the serial number of the board but instead when it's first run creates a (hopefully) unique fingerprint and that is what identifies a specific Pi.

So, for example, when I have the same Pi but with different SD cards in it I get different fingerprints when I ssh into it.

Yes, there's a serial-number hard-coded into the SoC (you can see yours with "cat /proc/cpuinfo"), and the serial number determines the Ethernet MAC address (you can see yours with "ifconfig"), and on a network using DHCP, each unique MAC address gets assigned a different IP address, and it's the different IP address that SSH noticed

edit: ...she swallowed the dog to catch the cat, ...

Nearly all the cables will need to be in place before any software can be run. And none of them will fit correctly in the wrong holes. And the obvious solution is to show a picture instead of trying to describe by colour alone.

Yes, of course - not a guide for connecting the cables but a guide for the kids to understand how their pi works (given that the Model-As will have transparent cases).
Future RPi revisions may have some connectors shifted around - there needs to be some kind of way of detecting what release of the board you're running on in order to show the correct picture.
Also - future RPi revisions will surely have more GPIO pins (in place of the multiple ground pins in the actual header)

So, is the serial number from /proc/cpuinfo REALLY random ?

there needs to be some kind of way of detecting what release of the board you're running on in order to show the correct picture.

Code: Select all

cat /proc/cpuinfo | grep Revision

(although I don't know what that's really indicating), and look at the area D7 on page 2 of the schematics. Anyone know if there's anything written/included in the distros to read those CONFIG lines?

[Gert van Loo]

The external four config GPIO pins are not used. Everything is in the on-chip OTP.

The external four config GPIO pins are not used. Everything is in the on-chip OTP.

They're not currently used, or they won't ever be used on the current board revision? i.e. would it be "safe" for someone to use them as additional user-controlled GPIO lines? Or could that assumption be messed up by a future firmware update?

Could you also comment re: whether the serial number is random or not

[dom]

They're not currently used, or they won't ever be used on the current board revision? i.e. would it be "safe" for someone to use them as additional user-controlled GPIO lines? Or could that assumption be messed up by a future firmware update?

They won't ever be used.

Could you also comment re: whether the serial number is random or not

http://dilbert.com/strips/comic/2001-10-25/

They're not currently used, or they won't ever be used on the current board revision? i.e. would it be "safe" for someone to use them as additional user-controlled GPIO lines? Or could that assumption be messed up by a future firmware update?

They won't ever be used.

Oooh! So I guess (with some very delicate soldering) they could be used to add the missing I2S interface? http://elinux.org/RPi_BCM2835_GPIOs#GPIO28

Could you also comment re: whether the serial number is random or not

http://dilbert.com/strips/comic/2001-10-25/

See also http://www.xkcd.com/221/
What I meant was, is the serial number definitely pseudo-randomly generated, and not some kind of guaranteed-unique sequential numbering? (and if so, isn't that a bit arbitrary?)

the number definitely is solid when you ask for it with cat /proc/cpuinfo - and it follows the hardware when moving SD cards around - because my pi count is greater than one, I have them physically labelled on the Ethernet Port (much like the early Betas) and all my card/builds have a 'whichpi' command in /usr/local/bin which tells me which one is running that distro

Yeah, the serial-number is definitely hardcoded into the SoC (i.e. constant & independent of SD-card). The question is how this serial-number is determined/calculated/guessed (during the 'build process'), not where it's stored

[rurwin]

What I meant was, is the serial number definitely pseudo-randomly generated, and not some kind of guaranteed-unique sequential numbering? (and if so, isn't that a bit arbitrary?)

Those are the same thing. Standard pseudo-random number algorithms just serve numbers out of their range in a pseudo-random but determinate order. Each number is the seed of the next, so no number repeats until the whole sequence does. Libraries then reduce the raw number into the range you want in the best way to enhance the apparent randomness.

So do RS and E14 have blocks of serial numbers? Or are the SoCs numbered before they're supplied to RS and E14? Is there more than one chip maker supplying SoCs to the board factories? And do they have blocks of serial numbers?

We Should Be Told!

Each number is the seed of the next, so no number repeats until the whole sequence does.

...assuming that each RPi is fed a specific seed, which may not necessarily be the case
viewtopic.php?f=28&t=5486

Edit: the reason I'm curious is it'd be nice to know if we can rely on the MAC address being globally unique, or if there's a very slim chance (as hinted at earlier) that two RPis could have the same MAC address (in which case we'd need to use the longer serial-number as the GUID instead).

[rurwin]

There are 24 bits of MAC address. If all those bits are being used, and all values are equally likely, then the birthday paradox is not a problem for a small population of RaspPis, say in a single school. However it would be a problem globally.

The birthday paradox formula is P2 = 1- ( d! / ( (d-n)! d^n ))
Where:
P2 is the probability of two or more MAC addresses clash.
d = 2^24 = 16,777,216
n is the number of RaspPis in one place, this is never going to be much higher than 100

We can calculate the bracketed section of this as follows:

Code: Select all

>>> t = 1.0
>>> for i in range(16777216-100, 16777216):
...     t = t * i / 16777216
...
>>>> print t
0.999398173056

So P2 is 1-0.999398173056 = 0.000601826944 or 0.0601826944 %

For n=500 P2 = 0.74%.
For n = 1000, P2 = 2.9%, so that is getting significant
For n = 10,000 P2 = 95%

(Someone is now going to blow holes in my algebra.)

There are 24 bits of MAC address. If all those bits are being used, and all values are equally likely, then the birthday paradox is not a problem for a small population of RaspPis, say in a single school. However it would be a problem globally.

The birthday paradox formula is P2 = 1- ( d! / ( (d-n)! d^n ))
Where:
P2 is the probability of two or more MAC addresses clash.
d = 2^24 = 16,777,216
n is the number of RaspPis in one place, this is never going to be much higher than 100

We can calculate the bracketed section of this as follows:

Code: Select all

>>> t = 1.0
>>> for i in range(16777216-100, 16777216):
...     t = t * i / 16777216
...
>>>> print t
0.999398173056

So P2 is 1-0.999398173056 = 0.000601826944 or 0.0601826944 %

For n=500 P2 = 0.74%.
For n = 1000, P2 = 2.9%, so that is getting significant
For n = 10,000 P2 = 95%

(Someone is now going to blow holes in my algebra.)

That's no problem as long as those many Raspis are not connected to the very same switch or router. Once the get their own IP address (or NAT translation), that's everything that matters on the net beyond that point.

Model-As will have transparent cases

YEP!! Where's this bit of information coming from?

Did I missed any recent official statement/post about Model-A's cases? I know it's planned that (by autumn) Model-A will be sold with a case already included in the 25USD price and that that case will be also sold apart (for Model-B owners), but that's all. Any additional info about that case (or actual pics) would be highly appreciated.

YEP!! Where's this bit of information coming from?

From The-Word-Of-Liz.

I remember reading in a couple of off-topic threads that Liz likes the idea of transparent cases so the kids can see the innards of the computer. And as we all know that Liz rules the Foundation with an iron fist (helped by Mooncake, her advisor), so it will be.

But enough off-topics, the numerologists want to find out the mistery of Raspberry Pi the serial number. Of you XOR the serial numbers of any two Model A & Model B RPis will you get winning lottery numbers ?

My Farnell-sources R-Pi has a serial of c5a142f6 in /proc/cpuinfo (that's 3315679990 in decimal).

On the board, there are some numbers etched on the ethernet port (google says it's just the connector part number, identical on all R-Pi's) and a physical label on the underside that reads FN120512799.

What is that physical label? Maybe a serial number from Farnell (i.e., not from the foundation and not necessarily present on boards sourced elsewhere)?

Is it correct to assume there is no way to get to the SoC serial without booting up the board?

The Farnell no just looks like a date code, mine are

FN 120606 nnn shipped 19th of June 2012, and FN 120721 xxx and yyy shipped 23rd July (only 6 days from order!)

suggesting the label added when finally packed into boxes and they are not expecting more than 1000 per day!

I would be very surprised if Ethernet MAC addresses not unique, that is such an established standard and I'm sure helps fund the IEEE.

What is that physical label? Maybe a serial number from Farnell (i.e., not from the foundation and not necessarily present on boards sourced elsewhere)?

There's more info/discussion about these physical stickers in this thread viewtopic.php?f=28&t=9524
(and lots of comparison pictures here: http://elinux.org/RaspberryPi_Boards )

Is it correct to assume there is no way to get to the SoC serial without booting up the board?

Correct (unless you write it down somewhere ). It's probably possible to also read the serial number using JTAG (header P2), but only Broadcom employees will have access to the BCM2835 JTAG.