Test Whether Raspberry Pi Has 512MB RAM


89 posts   Page 1 of 4   1, 2, 3, 4
by NerdUno » Wed Oct 17, 2012 1:58 pm
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
User avatar
Posts: 63
Joined: Wed Aug 15, 2012 1:35 pm
by RaTTuS » Wed Oct 17, 2012 2:10 pm
Oo
it's easier to do
free -h
as ^ that will not show you anything about memory
http://www.catb.org/esr/faqs/smart-questions.html <- ask smart Questions
"That's not right, the badgers have moved the goalposts."
1QC43qbL5FySu2Pi51vGqKqxy3UiJgukSX - Prosliver FTW
User avatar
Posts: 5566
Joined: Tue Nov 29, 2011 11:12 am
Location: North West UK
by texy » Wed Oct 17, 2012 2:12 pm
...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
"2.8inch TFT LCD + Touch screen" add-on boards for sale here :
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=93&t=65566
50p goes to the Foundation ;-)
Forum Moderator
Forum Moderator
Posts: 2449
Joined: Sat Mar 03, 2012 10:59 am
Location: Berkshire, England
by milhouse » Wed Oct 17, 2012 2:28 pm
RaTTuS wrote: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.
Posts: 555
Joined: Mon Jan 16, 2012 12:59 pm
by RaTTuS » Wed Oct 17, 2012 2:30 pm
revision number is not going to help
http://www.catb.org/esr/faqs/smart-questions.html <- ask smart Questions
"That's not right, the badgers have moved the goalposts."
1QC43qbL5FySu2Pi51vGqKqxy3UiJgukSX - Prosliver FTW
User avatar
Posts: 5566
Joined: Tue Nov 29, 2011 11:12 am
Location: North West UK
by milhouse » Wed Oct 17, 2012 2:34 pm
RaTTuS wrote: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... :)
Last edited by milhouse on Wed Oct 17, 2012 2:45 pm, edited 1 time in total.
Posts: 555
Joined: Mon Jan 16, 2012 12:59 pm
by dom » Wed Oct 17, 2012 2:42 pm
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.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4058
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by milhouse » Wed Oct 17, 2012 2:46 pm
dom wrote: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! :)
Posts: 555
Joined: Mon Jan 16, 2012 12:59 pm
by NerdUno » Thu Oct 18, 2012 5:25 pm
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.
User avatar
Posts: 63
Joined: Wed Aug 15, 2012 1:35 pm
by LenReinhart » Thu Oct 18, 2012 8:03 pm
"top" will show you how much memory the os has.
Posts: 21
Joined: Fri Sep 07, 2012 5:14 pm
by dom » Thu Oct 18, 2012 10:16 pm
NerdUno wrote: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).
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4058
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by Mortimer » Thu Oct 18, 2012 10:37 pm
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.
User avatar
Posts: 719
Joined: Sun Jun 10, 2012 3:57 pm
by milhouse » Thu Oct 18, 2012 10:48 pm
dom wrote: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).
Posts: 555
Joined: Mon Jan 16, 2012 12:59 pm
by dom » Thu Oct 18, 2012 11:01 pm
milhouse wrote: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.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4058
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by milhouse » Thu Oct 18, 2012 11:20 pm
dom wrote: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?
Posts: 555
Joined: Mon Jan 16, 2012 12:59 pm
by sraue » Fri Oct 19, 2012 8:44 pm
dom wrote: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
Posts: 144
Joined: Tue Feb 28, 2012 12:36 am
Location: Switzerland
by dextrus » Fri Oct 19, 2012 10:11 pm
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
Have more FUN with your Pi. Visit www.pi-fun.com
Posts: 119
Joined: Tue Jan 24, 2012 10:10 pm
Location: Eastleigh, Hampshire
by milhouse » Fri Oct 19, 2012 10:14 pm
dextrus wrote:Can someone else confirm that the 192Mb .elf only gives 256Mb free RAM on a 512Mb Pi please?


Confirmed.
Posts: 555
Joined: Mon Jan 16, 2012 12:59 pm
by dextrus » Fri Oct 19, 2012 10:16 pm
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
Have more FUN with your Pi. Visit www.pi-fun.com
Posts: 119
Joined: Tue Jan 24, 2012 10:10 pm
Location: Eastleigh, Hampshire
by milhouse » Fri Oct 19, 2012 10:19 pm
dextrus wrote: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.
Posts: 555
Joined: Mon Jan 16, 2012 12:59 pm
by dextrus » Fri Oct 19, 2012 10:26 pm
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
Have more FUN with your Pi. Visit www.pi-fun.com
Posts: 119
Joined: Tue Jan 24, 2012 10:10 pm
Location: Eastleigh, Hampshire
by dextrus » Fri Oct 19, 2012 10:34 pm
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
Have more FUN with your Pi. Visit www.pi-fun.com
Posts: 119
Joined: Tue Jan 24, 2012 10:10 pm
Location: Eastleigh, Hampshire
by milhouse » Fri Oct 19, 2012 10:38 pm
dextrus wrote: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).
Posts: 555
Joined: Mon Jan 16, 2012 12:59 pm
by dextrus » Fri Oct 19, 2012 10:42 pm
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
Have more FUN with your Pi. Visit www.pi-fun.com
Posts: 119
Joined: Tue Jan 24, 2012 10:10 pm
Location: Eastleigh, Hampshire
by milhouse » Fri Oct 19, 2012 10:45 pm
dextrus wrote: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?
Posts: 555
Joined: Mon Jan 16, 2012 12:59 pm