Hello, On 2015-01-23 07:35, Kukjin Kim wrote:
Marek Szyprowski wrote:Last 22 MiB is RAM is reserved by secure monitor code and cannot be accessed from Linux kernel, so adjust total RAM size to 0x7EA00000 (2 GiB - 22 MiB). This fixes random 'imprecise kernel abort' kernel failures. Signed-off-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> --- arch/arm/boot/dts/exynos5422-odroidxu3.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index f6fc9442f631..50843208860d 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts @@ -18,7 +18,7 @@ compatible = "hardkernel,odroid-xu3", "samsung,exynos5800", "samsung,exynos5"; memory { - reg = <0x40000000 0x80000000>; + reg = <0x40000000 0x7EA00000>; }; chosen { --Hi, Maybe is it related to the SoC not only for odriodxu3 board. If so, following would be better? ---8<------------8<--- diff --git a/arch/arm/boot/dts/exynos5800.dtsi b/arch/arm/boot/dts/exynos5800.dtsi index c0bb356..54840e3 100644 --- a/arch/arm/boot/dts/exynos5800.dtsi +++ b/arch/arm/boot/dts/exynos5800.dtsi @@ -13,6 +13,8 @@ * published by the Free Software Foundation. */ +/memreserve/ 0x80000000 0x1600000; + #include "exynos5420.dtsi" / {
I don't think so. It is related only to the setup done by the respective board's bootloader, not the SoC itself. It is already known that exynos 5800-based Chromebooks uses different bootloader setup (BL1+BL2+Trustzone) than Odroid XU3. Also please note that u-boot for Odroid XU3 limits the total memory passed to Linux kernel to 0x7EA00000, so we should not confuse the kernel about such 'reserved' regions. The same approach is used for Odroid X2/U3.
Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
