Enable full memory for 512MB Rev 2.0 Pi

I suspect it's just a logistics problem that rpi-update will fix sooner or later.

I haven't tried myself yet, but it should really just be bootcode.bin/loader.bin/start.elf that needs changed.  Probably not a good idea to use arm448_start.elf on a 256Mb board though, so it'll just be a case of identifying the board before giving you the option of what ones to pick.

I was half expecting some of the problems behind the recent posts on 512Mb doa's to be something daft like the old firmware not booting on the new board for some reason, but that doesn't appear to be the case.

Anyway, I'd definately recommend going the github route along with a self compiled kernel from the github source for a few good reasons:

1. you learn something new
2. you become independent of problems, or simply stuff like rpi-update not keeping up
3. you get to pick the bits you need - no more missing wifi drivers etc

If you try to use any of the new images on the 256MB it won't boot. Yes the process is simple, just copy whatever image you want to boot to start.elf and reboot. I only tested the 448/64MB memory split.

I've read some of the reports of issues with the 512MB, some of them smell more like a hardware/assembly issue.

If you want to do some kernel development/building I'd strongly recommend you setup your development environment in a separate Linux machine.

No, he says it won't boot. I take that to mean exactly what it says.

Gary Stewart wrote:

 

No, he says it won't boot. I take that to mean exactly what it says.

Well he actually said:

If you try to use any of the new images on the 256MB it won't boot.

I take that at face value. My reading of it is 'if you try to use any of the new (512Mb start.elf firmware) images in the 256Mb (physical Pi) it won't boot'

I don't believe I'm reading anything into it that isn't there ?

Lets clarify that by "new images" I meant the new ones created for the 512MB board.

The previous images for the 256MB board run OK on the 512MB, but you are not going to realize any benefits from the extra memory if you don't use one of the new kernels with the memory splits for the 512MB.

I guess that sooner or later we'll see a new distro where a 256MB image gets run first to enable running raspi-config where it can read cpuinfo and offer the option to change the memory splits now including the ones for 512MB boards.

Didn't see any comments about when such update to the distro may be available.

I can also boot the 512MB images using arm192_start.elf (512 MB version) on a 256MB Pi.

Gary Stewart wrote:

 

I can also boot the 512MB images using arm192_start.elf (512 MB version) on a 256MB Pi.

Ok, but you do realise that's a 256Mb start.elf ?  i.e. it's a 192/64 (=256) split ?  The 512Mb ones were arm256_start.elf arm384_start.elf arm448_start.elf arm496_start.elf or in other words the ones that actually require more than 256Mb.

Anyway, it's all changed now. There are (finally) no more versions of start.elf and a setting in config.txt can set the memory split, see

https://github.com/raspberrypi/firmware/commit/c57ea9dd367f12bf4fb41b7b86806a2dc6281176

Side note, the commit after that one https://github.com/raspberrypi/firmware/commit/c58f722d05cb9d9ea7d42378fdb2f1a947e6b046 I'm wondering how much ram the arm gets if you 'gpu_mem_512'.  Time to start a rumour about a 1GB ram Pi

Of course I do. Why would I use a memory size that isn't right ? And by the way, when I downloded it the start.elf file in the 512 MB images directory on github was also a copy of arm192_star.elf.

Are you aware of what GIT and github are ?

No, please enlighten me oh great and noble one. I mean yes, I have even built a few tool chains and systems (x86, ARM, PPC) from scratch using several different build systems

(crosstool, crosstool ng,  ptxdist, buildroot, linux from scratch).

So what was your point again ?

I really don't know what is your issue, but forget it. I was just asking in case you didn't know what GIT and github are.

That does seem like a good approach: the SD card distro image would be compatible for 256MB Pi and then on the first boot it could run a script to allow the user to enable the full memory of the 512MB Pi after rebooting (with whatever split they desire).

I'll recommend the manual approach from the article I linked to above until the utilities catch up.

thanks,

drew

That does seem like a good approach: the SD card distro image would be compatible for 256MB Pi and then on the first boot it could run a script to allow the user to enable the full memory of the 512MB Pi after rebooting (with whatever split they desire).

I'll recommend the manual approach from the article I linked to above until the utilities catch up.

thanks,

drew

Dan said: That does seem like a good approach: the SD card distro image would be compatible for 256MB Pi and then on the first boot it could run a script to allow the user to enable the full memory of the 512MB Pi after rebooting (with whatever split they desire).

I agree, it makes the transition easier and allows them to use one set of images for both versions.

Well now with yesterday changes that approach is no longer valid unless you dig on github to fish the previous commits.

I didn't run yet rpi-update to see what comes as an update, also I didn't check the forum or blog to see if there is any explanation about how to configure the mem split with the latest images and options added to bootcode.bin

Do you mean how now there is just a single start.elf?  Yeah, that confused me at first as the majority of instructions on the web for 512MB usage talk about the different versions based on CPU/GPU split.  The comment from popcornmix finally made me understand it:

https://github.com/raspberrypi/firmware/commit/c57ea9dd367f12bf4fb41b7b86806a2dc6281176

Remove plethora of start.elf files.

Now use start.elf and fixup.dat. Add config.txt paramater gpu_mem to select GPU mem and ARM gets the remainder. E.g. gpu_mem=64 Should handle 256M and 512M parts. The start_cd.elf and fixup_cd.dat will be used when gpu_mem=16. loader.bin no longer needed. Switch to compressed kernel images.

I see an additional commit on Oct 20 which states:

https://github.com/raspberrypi/firmware/commit/c58f722d05cb9d9ea7d42378fdb2f1a947e6b046

Add gpu_mem_256 and gpu_mem_512 config options to bootcode.bin

I'm not sure what that means though.

OK, running rpi-update on a test SD card ...

pi@raspberrypi:/boot$ sudo rpi-update

Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS

Performing self-update

ARM/GPU split is now defined in /boot/config.txt using the gpu_mem option!

We're running for the first time

Setting up firmware (this will take a few minutes)

This is how /boot looks now after rpi-update

pi@raspberrypi:/boot$ ls -l

total 16872

-rwxr-xr-x 1 root root   17764 Oct 22 22:30 bootcode.bin

-rwxr-xr-x 1 root root     142 Sep 18 12:52 cmdline.txt

-rwxr-xr-x 1 root root    1180 Sep 18 12:52 config.txt

-rwxr-xr-x 1 root root    2015 Oct 22 22:30 fixup_cd.dat

-rwxr-xr-x 1 root root    5277 Oct 22 22:30 fixup.dat

-rwxr-xr-x 1 root root     137 Sep 18 13:40 issue.txt

-rwxr-xr-x 1 root root 2104952 Oct 22 22:30 kernel_cutdown.img

-rwxr-xr-x 1 root root 9522048 Oct 22 22:30 kernel_emergency.img

-rwxr-xr-x 1 root root 2695192 Oct 22 22:30 kernel.img

-rwxr-xr-x 1 root root  522984 Oct 22 22:30 start_cd.elf

-rwxr-xr-x 1 root root 2347668 Oct 22 22:30 start.elf

The wiki page http://elinux.org/RPi_config.txt has been updated to show the new options ...

By default the config.txt does not show any of the new options.

Going for a reboot without changing anything ...

Seems that the default is 448/64:

[    0.000000] Memory: 448MB = 448MB total

[    0.000000] Memory: 448872k/448872k available, 9880k reserved, 0K highmem

[    0.000000] Virtual kernel memory layout:

[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)

[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)

[    0.000000]     vmalloc : 0xdc800000 - 0xe8000000   ( 184 MB)

[    0.000000]     lowmem  : 0xc0000000 - 0xdc000000   ( 448 MB)

[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)

[    0.000000]       .text : 0xc0008000 - 0xc04c0e78   (4836 kB)

[    0.000000]       .init : 0xc04c1000 - 0xc04e0b10   ( 127 kB)

[    0.000000]       .data : 0xc04e2000 - 0xc050e1c0   ( 177 kB)

[    0.000000]        .bss : 0xc050e1e4 - 0xc05b5128   ( 668 kB)

Will check later the config.txt options to confirm they work as explained on the wiki.

-J

Thanks for the tip.  Just ran the new rpi-update on a fresh Sept-18 and I can use gpu_mem in config.txt to enable the additional memory on the 512MB (went with gpu_mem=128 for now).