MX53Loco reports half of the total memory

Hi,

On a mx53loco board U-boot reports 1GB of total available memory:


U-Boot 2011.06-04814-geee1e2f (Aug 22 2011 - 13:37:53)

CPU:   Freescale i.MX53 family rev2.1 at 800 MHz
Reset cause: POR
Board: MX53 LOCO
DRAM:  1 GiB
MMC:   FSL_ESDHC: 0, FSL_ESDHC: 1
In:    serial
Out:   serial
Err:   serial
Net:   got MAC address from fuse: 00:04:9f:01:c6:57
FEC
Hit any key to stop autoboot:  0
MX53LOCO U-Boot >

When booting 3.1-rc3 only 512MB is reported:
...
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 512MB = 512MB total
Memory: 515420k/515420k available, 8868k reserved, 0K highmem
Virtual kernel memory layout:
...

Shouldn't the kernel report the whole 1GB?

Regards,

Fabio Estevam

On Wed, Aug 24, 2011 at 05:30:54PM -0300, Fabio Estevam wrote:

Hi,

On a mx53loco board U-boot reports 1GB of total available memory:


U-Boot 2011.06-04814-geee1e2f (Aug 22 2011 - 13:37:53)

CPU:   Freescale i.MX53 family rev2.1 at 800 MHz
Reset cause: POR
Board: MX53 LOCO
DRAM:  1 GiB
MMC:   FSL_ESDHC: 0, FSL_ESDHC: 1
In:    serial
Out:   serial
Err:   serial
Net:   got MAC address from fuse: 00:04:9f:01:c6:57
FEC
Hit any key to stop autoboot:  0
MX53LOCO U-Boot >

When booting 3.1-rc3 only 512MB is reported:
...

You probably missed the following in your boot log:

Ignoring RAM at b0000000-cfffffff (vmalloc region overlap).

...
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 512MB = 512MB total
Memory: 515420k/515420k available, 8868k reserved, 0K highmem
Virtual kernel memory layout:
...

Shouldn't the kernel report the whole 1GB?

Try compiling the kernel with CONFIG_VMSPLIT_2G. On my board this gives:

Memory: 512MB 512MB = 1024MB total
Memory: 1035204k/1035204k available, 13372k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
    vmalloc : 0xe0800000 - 0xf4000000   ( 312 MB)
    lowmem  : 0x80000000 - 0xe0000000   (1536 MB)
    modules : 0x7f000000 - 0x80000000   (  16 MB)
      .text : 0x80008000 - 0x803ab000   (3724 kB)
      .init : 0x803ab000 - 0x803c8000   ( 116 kB)
      .data : 0x803c8000 - 0x803ef4c0   ( 158 kB)
       .bss : 0x803ef4e4 - 0x8043cdc0   ( 311 kB)

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Hi Sascha,

On Wed, Aug 24, 2011 at 5:54 PM, Sascha Hauer [off-list ref] wrote:
...

Try compiling the kernel with CONFIG_VMSPLIT_2G. On my board this gives:

Excellent! That did the trick.

Would you like me to submit a patch for mx5_defconfig so that CONFIG_VMSPLIT_2G
is selected by default?

Thanks,

Fabio Estevam

On Wed, Aug 24, 2011 at 10:54:16PM +0200, Sascha Hauer wrote:

On Wed, Aug 24, 2011 at 05:30:54PM -0300, Fabio Estevam wrote:

quoted

Hi,

On a mx53loco board U-boot reports 1GB of total available memory:


U-Boot 2011.06-04814-geee1e2f (Aug 22 2011 - 13:37:53)

CPU:   Freescale i.MX53 family rev2.1 at 800 MHz
Reset cause: POR
Board: MX53 LOCO
DRAM:  1 GiB
MMC:   FSL_ESDHC: 0, FSL_ESDHC: 1
In:    serial
Out:   serial
Err:   serial
Net:   got MAC address from fuse: 00:04:9f:01:c6:57
FEC
Hit any key to stop autoboot:  0
MX53LOCO U-Boot >

When booting 3.1-rc3 only 512MB is reported:
...

You probably missed the following in your boot log:

Ignoring RAM at b0000000-cfffffff (vmalloc region overlap).

quoted

...
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 512MB = 512MB total
Memory: 515420k/515420k available, 8868k reserved, 0K highmem
Virtual kernel memory layout:
...

Shouldn't the kernel report the whole 1GB?

Try compiling the kernel with CONFIG_VMSPLIT_2G. On my board this gives:

Or enable highmem.

On Wed, Aug 24, 2011 at 6:43 PM, Russell King - ARM Linux
[off-list ref] wrote:
...

quoted

quoted

Shouldn't the kernel report the whole 1GB?

Try compiling the kernel with CONFIG_VMSPLIT_2G. On my board this gives:

Or enable highmem.

Enabling CONFIG_HIGHMEM also made the whole 1GB to be reported.

On Thu, Aug 25, 2011 at 08:53:49AM -0300, Fabio Estevam wrote:

"config HIGHMEM
	bool "High Memory Support"
	depends on MMU
	help
	  The address space of ARM processors is only 4 Gigabytes large
	  and it has to accommodate user address space, kernel address
	  space as well as some memory mapped IO. That means that, if you
	  have a large amount of physical memory and/or IO, not all of the
	  memory can be "permanently mapped" by the kernel. The physical
	  memory that is not permanently mapped is called "high memory".

	  Depending on the selected kernel/user memory split, minimum
	  vmalloc space and actual amount of RAM, you may not need this
	  option which should result in a slightly faster kernel.

	  If unsure, say n."

So is it correct to say that CONFIG_VMSPLIT_2G is preferred over
CONFIG_HIGHMEM due to the "should result in a slightly faster kernel."
statement above?

It depends what your userspace is expecting.  There's a few issues to
consider:

1. The 3G split is the well established normal split both on ARM and x86.
2. Userspace is sparsely populated into three or four main regions.
3. There are some programs which assume that there's 3G of userspace
   available (some have hard-coded constants for this - notorious
   examples a garbage collection libraries, though they may have been
   fixed with the advent of stack placement randomization.)

Reducing the size of userspace squashes the regions together, which may
limit the amount of memory available to any one process.  You won't see
that effect from just running a shell or 'cat' etc, but you may find it
if you have a heavy-weight application wanting to allocate lots of
memory.

Out of the two, highmem is the overall safer option in this regard because
it allows you to keep the standard user layout while still having access
to more physical memory.

It may be slower as a result of the kernel having to map/unmap highmem
pages during startup, but (again, depending on your userspace behaviour)
it may make no difference to your userspace once its cached the user
programs in memory.