View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001164 | fss5pv210_Linux | U-Boot | public | 2012-07-20 10:55 | 2014-01-28 11:42 |
| Reporter | Keller | Assigned To | |||
| Priority | low | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | armStoneA8-V1.1 | ||||
| Target Version | fss5pv210-V2.0 | Fixed in Version | fss5pv210-V2.0 | ||
| Summary | 0001164: On armStoneA8 with 512MB of RAM, Linux uses only 256MB | ||||
| Description | Linux only shows 256MB of available RAM even on boards where there are 512MB equipped. However NBoot and U-Boot correctly show 512MB. | ||||
| Steps To Reproduce | Show 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 | http://forum.fs-net.de/viewtopic.php?f=55&t=3233 | ||||
|
|
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) saveenv This workaround is rather easy to do and therefore the low priority of this bug. |
