View Issue Details

IDProjectCategoryView StatusLast Update
0001164fss5pv210_LinuxU-Bootpublic2014-01-28 11:42
ReporterKeller Assigned To 
Status resolvedResolutionfixed 
Product VersionarmStoneA8-V1.1 
Target Versionfss5pv210-V2.0Fixed in Versionfss5pv210-V2.0 
Summary0001164: On armStoneA8 with 512MB of RAM, Linux uses only 256MB
DescriptionLinux only shows 256MB of available RAM even on boards where there are 512MB equipped. However NBoot and U-Boot correctly show 512MB.
Steps To ReproduceShow free memory:

# free
             total used free shared buffers
Mem: 254192 49720 204472 0 0
-/+ buffers: 49720 204472
Swap: 0 0 0

Or show /proc/meminfo:

# cat /proc/meminfo
MemTotal: 254192 kB
MemFree: 204472 kB
Buffers: 0 kB
Cached: 11732 kB

Or look at the boot messages of the kernel:

Memory: 256MB = 256MB total
Memory: 254044k/254044k available, 8100k reserved, 0K highmem
Virtual kernel memory layout:
    vector : 0xffff0000 - 0xffff1000 ( 4 kB)
    fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
    vmalloc : 0xd0800000 - 0xff000000 ( 744 MB)
    lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
    modules : 0xbf000000 - 0xc0000000 ( 16 MB)
      .text : 0xc0008000 - 0xc0501848 (5095 kB)
      .init : 0xc0502000 - 0xc0527000 ( 148 kB)
      .data : 0xc0528000 - 0xc05634c0 ( 238 kB)
       .bss : 0xc05634e4 - 0xc05a06d8 ( 245 kB)
Forum Link



2012-07-20 11:03

manager   ~0000740

This is not a real bug. It depends on whether the kernel image is loaded to the first or the second memory bank before starting it. The base address of the bank of the image determines the base address of the virtual kernel address space. Banks before this address can't be used in Linux. So if the image is loaded in the second bank, Linux only uses 256MB of RAM. If it is loaded in the first bank, it will use all available 512MB.

We have already implemented an automatic environment variable $(loadaddr) in U-Boot that automagically contains a suited load address at the beginning of the available RAM. However the default bootcmd of the default environment in release V1.0 and V1.1 does not use this variable and loads the kernel to the fix address 0x41000000 instead. This unfortunately is in the second bank on a 512MB board.

So we just have to change this default bootcmd definition and everything will work fine. In the meanwhile the user can set a fixed bootcmd with

setenv bootcmd nand read.jffs2 \$(loadaddr) Kernel \; bootm \$(loadaddr)

This workaround is rather easy to do and therefore the low priority of this bug.