A small amount of one of the aliases is used for gpu peripheral access.
The arm accesses gpu memory space through a coarse MMU that allows 64 blocks of 16M to be mapped in.
On Pi0/Pi1 we use 32 of these blocks to access 512M of sdram and one block for gpu peripherals.
On Pi2/Pi3 we use 63 of these blocks to access 1008M of sdram and one block for gpu peripherals.
Because of this mapping on Pi2/Pi3 the top 16M of sdram cannot be seen by the arm and is currently not used.
It makes sense for the gpu to use this top 16M of sdram, but there are complications.
Some parts of gpu memory are accessed from the arm, e.g. the touchscreen and led drivers use a shared block of memory.
Debugging tools like vcdbg read gpu memory to extract gpu logs and dumps of the memory heaps.
I believe I have worked around these issues (using arm allocated buffers for communication and using dma to access gpu memory from vcdbg).
If you are using rpi-update firmware/kernel, it should be possible to enable this extra memory.
If you add to config.txt:
- Code: Select all
The extra 16M will be enabled. If gpu_mem is not specified we will increase gpu memory from 64M to 76M and arm memory from 944M to 948M
as the extra gpu memory improves Chromium's hardware video decode performance.
You are free to explicitly set it (e.g. gpu_mem=64) if you prefer the extra memory to purely be on the arm.
You can test the memory available with:
- Code: Select all
vcgencmd get_mem arm
vcgencmd get_mem gpu
This is only useful on Pi2/Pi3. Pi0/Pi1 have always had address space for their 512M of sdram and peripherals to be accessed without difficulty.
I have seen reports of crashes occurring with "total_mem=1024" from kodi users. Those users have reported "total_mem=1023" is stable.
I haven't been able to reproduce the crash. Be aware that this setting is experimental and could cause instability so don't enable on a critical system.
Please start with "total_mem=1024". Instructions for how to reproduce a crash with this would be very useful.