summaryrefslogtreecommitdiff
path: root/configs/Bananapro_defconfig
diff options
context:
space:
mode:
authorSiarhei Siamashka <siarhei.siamashka@gmail.com>2014-12-24 18:58:17 +0200
committerHans de Goede <hdegoede@redhat.com>2015-01-14 14:56:37 +0100
commitc3d2b963c6a0b85a60c918b970db59c5b210fc98 (patch)
tree87a1eb74c1f01c65f3e1e6fd570f5473003a395c /configs/Bananapro_defconfig
parentf4f0df09b9686888e4865b245e2c7c310ff5530c (diff)
downloadu-boot-imx-c3d2b963c6a0b85a60c918b970db59c5b210fc98.zip
u-boot-imx-c3d2b963c6a0b85a60c918b970db59c5b210fc98.tar.gz
u-boot-imx-c3d2b963c6a0b85a60c918b970db59c5b210fc98.tar.bz2
sunxi: Fix buggy sun6i/sun8i DRAM size detection logic
After reboot, reset or even short power off, DRAM typically retains the old stale data for some period of time (for this type of memory, the bits of data are stored in slowly discharging capacitors). The current sun6i/sun8i DRAM size detection logic, which is inherited from the Allwinner code, relies on using a large magic signature with the hope that it is unique enough and unlikely to ever accidentally match this leftover garbage data in RAM. But this approach is inherently unsafe, as can be demonstrated using the following test program: /***** A testcase for reproducing the problem ******/ void main(int argc, char *argv[]) { size_t size, i; uint32_t *buf; /* Allocate the buffer */ if (argc < 2 || !(size = (size_t)atoi(argv[1]) * 1048576) || !(buf = malloc(size))) { printf("Need buffer size in MiB as a cmdline argument\n"); exit(1); } /* Fill it with the Allwinner DRAM "magic" values */ for (i = 0; i < size / 4; i++) buf[i] = 0xaa55aa55 + ((uintptr_t)&buf[i] / 4) % 64; /* Try to reboot */ system("reboot"); /* And wait */ for (;;) {} } /***************************************************/ If this test program is run on the device (giving it a large chunk of memory), then the DRAM size detection logic in u-boot gets confused after reboot and fails to initialize DRAM properly. A better approach is not to rely on luck and abstain from making any assumptions about the properties of the leftover garbage data in RAM. Instead just use a more reliable code for testing whether two different addresses refer to the same memory location. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Diffstat (limited to 'configs/Bananapro_defconfig')
0 files changed, 0 insertions, 0 deletions