Identifying RPI revision

[BunBun]

I ordered a RPI from newarc back in november. I got mine in a few weeks. When I ordered and when I got it everything indicated I was getting the 512mb version. Now not knowing anything about RPI's or linux at the time I did not know how to verify this.

I think I got something wonky. The board looks like a rev 2 board (according to pictures online as mine as mounting holes) but I remember when setting up something it appeared to only have 256mb of ram. So I check cat /proc/cpuinfo and the revision number is 0002 which on the wiki says this is a revision 1 board.

Also I check free -m and total mem is only 182mb which after shared with graphics that means I do only have a 256mb version right?

How would I go about correcting this? Or am I screwed and have to order a new pi if I want to get the correct one?

[aelsas]

Hi,

cat /proc/cmdline | awk -v RS=" " -F= '/boardrev/ { print $2 }'

gives the revision.

Best regards

Alex

[DirkS]

cat /proc/cmdline | awk -v RS=" " -F= '/boardrev/ { print $2 }'

Will this also give the correct revision if you're running a 512mb pi with old firmware?
IIRC the rev reported in '/proc/cpuinfo' in these cases is *not* correct (and also the full amount of RAM is not recognised)

Gr.
Dirk.

[aelsas]

Hi,

you can find more details here:
http://raspberryalphaomega.org.uk/?p=428
http://www.raspberrypi.org/phpBB3/viewt ... 63&t=32733

Best regards

Alex

[pluggy]

Are you using the latest image ?. Early firmware can misrepresent issues and memory. We had a spate of 'why is my 512 Pi only 256 ?' posts when the 512s first came out.

uname -a

would give us something to go on in this respect.

[BunBun]

cat /proc/cmdline | awk -v RS=" " -F= '/boardrev/ { print $2 }'

returns

0x2

uname -a

reterns

Linux raspberry 3.1.9adafruit+ #10 PREEMPT Thu Aug 30 20:07:05 EDT 2012 armv61 GNU/Linus

I am going to look for the latest release now and try that

[pluggy]

An image that age is unlikely to see all the memory.

The download link at the top of this page for something a bit more up to date.

[aelsas]

Well,

0x2 is the first revision...

Best regards

Alex

[jojopi]

0x2 is the first revision...

But OP says it has mounting holes. Is it more likely that someone drilled holes in a Rev1, and it still works, or that the revision number is reported incorrectly?

[aelsas]

Hi,

at the moment I would blame it on the old OS version.

Best regards

Alex

[BunBun]

I had a downloader on my computer for fedora remix. I just let that go on the SD card and now

free -m
total 436mb

cat /proc/cpuinfo
Revision: 000f

Yay! Thanks guys.

[Joe Schmoe]

Two things:

1) Clearly, if everything is working correctly, the "revision" info you get from /proc/cpuinfo and from /proc/cmdline should be the same. But it seems that there are pathological cases where things can be out of sync. Can anyone state a) What these pathological cases are and b) Which one (of the files under /proc) is more authoritative in those cases?

2) Is there a table anywhere telling what these revision numbers mean? E.g., what does 0xf mean?

[aelsas]

Hi,

http://raspberryalphaomega.org.uk/?p=428

explains the codes.

Best regards

Alex

[DirkS]

b) Which one (of the files under /proc) is more authoritative in those cases?

AFAIK both report the same. I cannot see anything in this topic that indicates otherwise.

If you're using ancient firmware there's a chance you get the wrong rev. And it's not impossible the same will happen again in the future.

Gr.
Dirk.

[jojopi]

1) Clearly, if everything is working correctly, the "revision" info you get from /proc/cpuinfo and from /proc/cmdline should be the same. But it seems that there are pathological cases where things can be out of sync. Can anyone state a) What these pathological cases are and b) Which one (of the files under /proc) is more authoritative in those cases?

I would be surprised if they ever differ, because they are both ultimately reported by the same running firmware.

I think the main pathology is that factories misprogrammed the revision on some batches, especially just after the move to 512MiB. I have a board that should have been 0xe (Sony B 512) but was factory programmed as 0x5 (Qisda B 256) and reported as such on original firmware. On newer firmware it not only reports as 0xf (Qisda B 512), but is actually re-programmed as such. So now it is recognised as 0xf even on very old firmware that does not support 512MiB. I expect the OP in this thread will find the same.

More recently, boards with 512MiB Hynix RAM will not boot at all on old firmware. So the advice must always be to use the latest images.

[Burngate]

Most authoritative answer: get a magnifying glass, see what it says on the chip.
2G is 256M, 4G for 512M.
If software says different, it's wrong!