Test Whether Raspberry Pi Has 512MB RAM

[NerdUno]

Haven't gotten one yet, but here's a simple BASH script that should tell you whether your new Raspberry Pi has 512MB of RAM:

Code: Select all

REVISION=`cat /proc/cpuinfo | grep Revision | cut -f 2 -d ":"`
if [ ${REVISION:(-2)} -gt "04" ];
then
 echo "512MB RAM"
else
 echo "256MB RAM"
fi

[RaTTuS]

Oo
it's easier to do
free -h
as ^ that will not show you anything about memory

[texy]

...or just look at the device on the Pi - if its got K4P2G324 its a 256MB Pi, if its got K4P4G324 its a 512MB Pi.

Texy

[milhouse]

Oo
it's easier to do
free -h
as ^ that will not show you anything about memory

That's not going to help if you've booted a 512MB device with 256MB firmware - the only sure fire way is to check the revision number, or look at the markings on the RAM chip.

[RaTTuS]

revision number is not going to help

[milhouse]

revision number is not going to help

At this point in time, a Revision number (from /proc/cpuinfo) of 5 would strongly suggest a 512MB device, below 5 and it's almost certainly 256MB.

Just noticed one of the 512MB Pi I received on Monday has a revision code of 000f (15, I guess) while the other (both came together) is a 0005:

Code: Select all

pi@raspberrypi ~ $ cat /proc/cpuinfo
Processor       : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 996.14
Features        : swp half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2708
Revision        : 100000f

And the script posted by the OP doesn't take the warranty voided bit into consideration...

[dom]

The correct check for 512M part is:
(board_rev & 0xffffff) >= 10

unfortunately one of the manufacturers didn't update their OTP corrrectly and report 5. If you update to latest firmware we will correct that to 15.

[milhouse]

unfortunately one of the manufacturers didn't update their OTP corrrectly and report 5. If you update to latest firmware we will correct that to 15.

Aha, that explains why one of mine is now showing 15 (booted on latest firmware) and the other (on older firmware) still shows 5!

[NerdUno]

There needs to be a straight-forward way to use the same firmware for BOTH 256MB and 512MB boards. Otherwise, it will force those building apps for both platforms to release 2 different images with different firmware for every app. Thus far, the new firmware only provides memory split options for the 512MB boards. As I understand it, attempting to boot such an image on a 256MB system would hang which is not a good thing.

The workaround for now is you have to build an image for a 256MB board. Then, on first boot, you test whether it's a 512MB board. If it is, then you have to shuffle new firmware into place and reboot before 512MB is ever recognized. This is further complicated by the glitch in board numbering for 512MB boards by one of the manufacturers.

Simply stated, it's too complicated as it stands now. Seems like the firmware itself would be the logical place to embed logic that says... if this is a 256MB card, boot with start256.elf, otherwise boot with start512.elf. Then, app developers could move the desired start.elf memory configurations into both the start256 and start512 files. Every Raspberry Pi would be covered AND would boot. As noted, there aren't any 256MB options with the new firmware, and there are already 400,000+ of these boards in circulation. So it would be desirable to continue to support them. Just my $.02.

[LenReinhart]

"top" will show you how much memory the os has.

[dom]

There needs to be a straight-forward way to use the same firmware for BOTH 256MB and 512MB boards.

Indeed. And removing the plethora of start.elf variants would be nice too. Perhaps just specify how much RAM you want the GPU to have, then then ARM has can have the rest (of the 256M or 512M).

[Mortimer]

From a programming point of view the correct approach would seem to be the one that RaTTuS proposed (free -h). The program shouldn't need to worry about whether the RPi it is running on has a 256MB or 512MB RAM chip fitted, but rather what is actually available. That way, if a user has fired up a 512MB RPi with a 256MB start.elf file, the program will still run correctly, albeit not as well as it could do if a proper 512MB .

If there is a way for a program to accurately determine the underlying memory capacity of the RPi, then a prompt to the user that the star.elf file is not the optimum one for the machine would be a nice touch.

[milhouse]

Indeed. And removing the plethora of start.elf variants would be nice too. Perhaps just specify how much RAM you want the GPU to have, then then ARM has can have the rest (of the 256M or 512M).

Which is fine, but what if the OS wants 256MB GPU RAM on a 512MB board, but only 128MB on a 256MB, ie. different GPU allocations based on total available RAM (maybe with reduced functionality on the 256MB board)? This would suggest that two values are required (though this could default to a single value in some circumstances, such as when only 128MB or any value that works for both models is required).

[dom]

Which is fine, but what if the OS wants 256MB GPU RAM on a 512MB board, but only 128MB on a 256MB, ie. different GPU allocations based on total available RAM (maybe with reduced functionality on the 256MB board)? This would suggest that two values are required (though this could default to a single value in some circumstances, such as when only 128MB or any value that works for both models is required).

That makes it more complicated. The XBMC distros already handle this. They read board_rev and copy start.elf files as appropritate, so they could edit the config.txt.

We could have two options:
gpu_mem=64
gpu_mem_percent=25

You can pick one or the other. And if you pick both it sums them. E.g. that would give you 128M on a 256M board, and 192M on a 512M board.

[milhouse]

You can pick one or the other. And if you pick both it sums them. E.g. that would give you 128M on a 256M board, and 192M on a 512M board.

To be honest, that sounds more complicated to me...

Obviously I don't know how many different models of board there will be, but I'd have though that in most cases a single GPU allocation amount would suffice. However, if multiple comma delimited values were specified for GPU allocation, then the firmware should pick whichever value corresponds with the installed amount (that is the first number is for 256 models, the second number is for 512 models etc. - unspecified amounts would match the closest model, so the 512MB value for a 1Gig board, unless a third value is specified...)

gpu_allocation=128 <-- 128MB GPU for all models, leaving 128MB for 256MB and 384MB for 512 etc.
gpu_allocation=196,256 <-- 196MB GPU RAM on a 256 board, 256MB GPU RAM on a 512MB (or greater) board.
gpu_allocation=256 <-- Invalid on a 256MB board, but valid for a 512MB+... Maybe the OS isn't intended for 256MB boards, so display suitable error message?

[sraue]

That makes it more complicated. The XBMC distros already handle this. They read board_rev and copy start.elf files as appropritate, so they could edit the config.txt.

We could have two options:
gpu_mem=64
gpu_mem_percent=25

You can pick one or the other. And if you pick both it sums them. E.g. that would give you 128M on a 256M board, and 192M on a 512M board.

i like this solution with only one generic start.elf much more then all others.


example: if anyone creates a sdcard for a 512mb model wth a 256MB memory split this card will actually never work in a 256Mb model. with the actual solution we will run in much problems, if we create the sdcards on second pcs with install scripts... if you buy a sdcard with a OS preinstalled you must order the right one etc...

stephan

[dextrus]

I just got my 512Mb pi this evening, and tried the latest 192Mb split .elf. It's only giving me 256Mb in total according to top. I tried the 256Mb split and that works fine (phew, at least I do have a 512 Pi!).

Can someone else confirm that the 192Mb .elf only gives 256Mb free RAM on a 512Mb Pi please?

/Dextrus

[milhouse]

Can someone else confirm that the 192Mb .elf only gives 256Mb free RAM on a 512Mb Pi please?

Confirmed.

[dextrus]

Well, that's a disaster isn't it?

Does this mean that if you have a 512Mb Pi you *must* split the memory 256Mb or above to get the full RAM?

/Dextrus

[milhouse]

Well, that's a disaster isn't it?

Does this mean that if you have a 512Mb Pi you *must* split the memory 256Mb or above to get the full RAM?

/Dextrus

Not necessarily a disaster, but certainly not ideal - a better solution is on the list of things to do (and lets be fair, it's only become a problem with the introduction of the 512MB model, and I ain't complaining about that!)

You can split the memory on a 512MB in much the same way as the 256MB - that is, allocating either 16MB, 64MB, 128MB (and now also 256MB, but oddly, no 32MB) to the GPU with the remainder available for the ARM.

[dextrus]

True, but we know what we're talking about. The bulk of users will never see the extra ram. I also noticed that the new start.elf is a 128MB split, instead of 192Mb. I must test that one..

/Dextrus

[dextrus]

128Mb split (arm128_start.elf) also doesn't use the available memory. As far as I can tell. This is the default start.elf too.

/Dextrus

[milhouse]

128Mb split (arm128_start.elf) also doesn't use the available memory. As far as I can tell. This is the default start.elf too.

None of the sub-256 memory split elf's will give access to the full 512MB - the only way to access it is with the 256MB+ elfs (256/384/448/496). Other than the inability to swap the card between a 256 and 512 model, I don't really see a problem - they both allocate roughly the same RAM amounts to the GPU, with the remainder available to the ARM (the naming convention of the various elf files relates to the amount of RAM that will be available to the ARM).

[dextrus]

I simply can't understand why you don't think this is a problem. Try and think like normal people and get back to me.

/Dextrus

[milhouse]

I simply can't understand why you don't think this is a problem. Try and think like normal people and get back to me.

/Dextrus

What's the problem then, other than the one I acknowledged as being a problem?