Test Whether Raspberry Pi Has 512MB RAM

[quote="dom"]Updated firmware pushed:Removed plethora of start.elf files.Now uses start.elf and fixup.dat. Add config.txt parameter gpu_mem to select GPU mem and ARM gets the remainder. E.g. [code]gpu_mem=64[/code]Should handle 256M and 512M parts. The start_cd.elf and fixup_cd.dat will be used when gpu_mem=16.loader.bin is no longer needed.I've also switched to compressed kernel images.

droorzn wrote:1. What the differences of start.elf and fixup.dat with start_cd.elf and fixup_cd.dat?2. What is this code means?3. What is "*" in arm*_start.elf? in my SD card there are arm_128_start.elf,arm_192_start.elf,arm_224_start.elf and arm_240_start.elf?

1. The latter are cutdown versions without opengles/openmax/openvg/codec etc built in. They are used when gpu_mem=16.2. copies files in /root/.rpi-firmware to /boot as root user. 3. "*" is a wildcard. If you just type it in, it will delete all of: arm_128_start.elf,arm_192_start.elf,arm_224_start.elf and arm_240_start.elf.

If you wait a couple of days there will be a blog post, and easier ways of doing this - this is really for testers at the moment.

2 More: 1. Can i push the latest firmware by downloading from https://github.com/raspberrypi/firmware/tree/master/boot and copying to my SD Card with Windows PC ( I only use drag and drop)2. How do i check my memory split is already 512MB memory split? when i run rpi-update it show my memory is 240/16 and error code arm240.elf is not found

dom wrote:1. The latter are cutdown versions without opengles/openmax/openvg/codec etc built in. They are used when gpu_mem=16.2. copies files in /root/.rpi-firmware to /boot as root user. 3. "*" is a wildcard. If you just type it in, it will delete all of: arm_128_start.elf,arm_192_start.elf,arm_224_start.elf and arm_240_start.elf.

If you wait a couple of days there will be a blog post, and easier ways of doing this - this is really for testers at the moment.

number 2, only copies files? where the destination?Easier way don't help me understanding this. I just want to learn more, thanks for your answer.

Edit config.txt and set gpu_mem to whatever amount of memory (in megabytes) that you want allocated to the GPU - the remainder will be allocated to the ARM (system). So set gpu_mem=16 if you only want 16MB GPU RAM, and the maximum amount of system memory for applications.

davedriver wrote:The new firmware isn't working correctly for me on my 512MB Pi.

Answering my own question, the problem wasn't the firmware, but my kernel. I am still not sure what kernel parameter was limiting the memory available, but I have now updated the sources to 3.2.27 and rebuilt, and now it shows the correct amount of ARM RAM.

So next I need to go through the kernel again and strip out all the bloat.

thanks.. you have quite a setup .. I went to your website.. I see you use omxplayer..did you try it with gpu set to 32mb... it crashes when I set it that low .. also I associated omxplayer with mp4 and flv files so I can just click on them when under lxde...however I don't seem to have key command control then...

on my 512 board with 32 for gpu -- omxplayer only does audio but does notcrash system any longer.. @64mb all is well .. the overclock is still dodgy .. I really thought it was working great then file corruption .. fortunately fsck workedfor me .. this is on the firmware #250 as of today 14a55da ...

It has been running for quite some time today and the temp is 44. It gets up to 52 under load. I have a TO-220 heat sink on the memory chip. The SD card is a SanDisk Ultra 10, 32GB. I have been running the overclock as above since turbo first came out, first with my 256MB and now with the 512MB and todate had no memory corruption event. I have the little read out, that when hovered over, shows the speed, so I watch it shift back and forth from 700MHz to 1000MHz.

W. H. Heydt wrote:Since there was a post noting that the gpu_mem resolution really is 1MB, is the 16MB graphics the actual value to use the smaller footprint files, or is it, say, anything under 32MB?

Or to put in another way....what is the threshold below which the smaller files would be triggered?

I was curious about this, and what fixup_cd is for, also.

It seems with the current implementation that gpu_ram=15 boots the _cd but does not attempt to cut its ram any further below 16. gpu_ram=17 fails to boot, suggesting it is trying to restrict the full start.elf. gpu_ram=31 works, using start.elf, but this is not very useful because it is already below the level where the gpu can do serious graphics acceleration. (So I still wonder what fixup_cd.dat is for.)

Given that there are already values that fail to boot, it might make more sense to allow gpu_ram<16 to interpolate start_cd.elf (which might work for very small framebuffers), and to set the threshold somewhere between 16 and 32.

Regardless, this is a very elegant hack, especially compared to the previous system of pre-boot fixed allocations. I actually prefer this to true dynamic allocation. So thanks to Dom and Eben.

so ... you have a 512MB Piyou've told it, via config, to use a 256MB for the GPU (gpu_mem_512=256)which means ... there's 512 - 256 = 256MB for the CPUand top is telling you there's 256MB total (CPU) ram ...

where's the problem?

NOTE: top hasn't changed ... it's always told you how much CPU memory you have

so ... you have a 512MB Piyou've told it, via config, to use a 256MB for the GPU (gpu_mem_512=256)which means ... there's 512 - 256 = 256MB for the CPUand top is telling you there's 256MB total (CPU) ram ...

where's the problem?

NOTE: top hasn't changed ... it's always told you how much CPU memory you have

Okay. I was sure top would report total ram. Thanks for confirmation that it's working as intended.