From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F3BBBC10F0E for ; Fri, 12 Apr 2019 10:10:27 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BECCD2084D for ; Fri, 12 Apr 2019 10:10:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="n8dcbtKM"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="RU8Uov9d" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BECCD2084D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=pHCJZ1AeFF7Kv5GUUUXUywB3VCK0zX4vNrQdKhSrnIQ=; b=n8dcbtKMr25be3 vLeOjMIArX3OHqN3/YJBYWqBbmrVB+fwAizuZ1mBznTjenkCwLTmH6YzZUSUGAV0vmpkqCNtrQyID vETO9+eyHUKpUhR62JRNeU0UZz+dSxfTKaWkJ5VyZHaWBuQTjlXUlMExHLMf55XNo2K8velX03xGF jnnd6XHrt1PpUDckmkYuzVQt7nuWs6enRiYKUjswmNRrGTh7/LnK1YLSkB2qbBkqvHRA1ImMuP8ho hXGbTJjj5y9o6PyISKV2lKAvCrDRrFOJUnNHHst+l3TUIYZ43inv7rw5KitD+67rUPayv+qCdjzWw qGHMfBOhhHMoFmXuGL5Q==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hEt8Y-00059e-0i; Fri, 12 Apr 2019 10:10:22 +0000 Received: from mail-wm1-x343.google.com ([2a00:1450:4864:20::343]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hEt8U-00059K-B3 for linux-arm-kernel@lists.infradead.org; Fri, 12 Apr 2019 10:10:20 +0000 Received: by mail-wm1-x343.google.com with SMTP id v14so10287277wmf.2 for ; Fri, 12 Apr 2019 03:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=hbu/roQcvZUTYIsyFYfNjyVRbaluV6AD9oa78DqOXgA=; b=RU8Uov9dc+1fE2BvqtikoDDw6Fc3vTR7XbpdJXNxd1VH/eFO55TXgFexrcHmBSLG24 trezg03RtQiuH6LpyEgsg4s69nxBiNkblYpBKOGXRSGQoaQ9QRAzQvFG2dJDq89qlOV2 C9YRF6q6/rTlU7ZE7moYI0iBxbzCMUyWbj4kZpfCcwvANX8TbF62vRbzw/en6GiXKdt2 VdrJX8848TF8SC8yuoZvz3K+QeRncgXcmHMTEJtUgYcTkg3rfVFO8p58DTu5tss13w3K Vf8ChwNsmd7pnU6VYVJ0wMBpwBz8cWu2fZ0F9M7BY/SwRZh+1jscX6buTZj7RUwyrSXG Og7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=hbu/roQcvZUTYIsyFYfNjyVRbaluV6AD9oa78DqOXgA=; b=buPA77NyStGJYtTt6cFEH3FsZ9J22PS8mVoQQ2v3KCi71q8AJGU6hRTg2EG5Mkh0lV fjM+V13PQctx+zxKdUwCUr54VYekZGUR2KB7f5G//ANhsu7WPgH2Sv+37q7p72za+3Jk BwEJ0ZcVDE88rBYE9NrWdHZZjD9lPqa0fCJQLCWgA/RRP2HKad3o2GYPLxJZcv8cUVcq 78kAdeU2Yp0WwQlAiUuD2sjGEayHQrfBfNUv85+yvkuz8lXQB1ctd0rpL48VG1dNz75S ZxsP6Yg1NqCZTepItFDQywt8zK5GLA4vYJy9jpTMQtBa3rYzAI+zfDciTeKiqNdYupAm 1DyA== X-Gm-Message-State: APjAAAVBZ2tBEZ7fOEenYF6OqWFIE/Z1pl1ai06jRCl5JOrGAY40MLSj FAymmkVBik7N79l/71BnBtueUw== X-Google-Smtp-Source: APXvYqwHm1nPOE1IdOqBIcA9JwYZcJr8fiu8wqrxWHUu4tJIuLX8PN7RxUmqHh+Yv3VieYiNms3wMw== X-Received: by 2002:a1c:a64d:: with SMTP id p74mr10942782wme.89.1555063816646; Fri, 12 Apr 2019 03:10:16 -0700 (PDT) Received: from apalos (athedsl-165181.home.otenet.gr. [85.75.188.219]) by smtp.gmail.com with ESMTPSA id b204sm11245581wmh.29.2019.04.12.03.10.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Apr 2019 03:10:15 -0700 (PDT) Date: Fri, 12 Apr 2019 13:10:13 +0300 From: Ilias Apalodimas To: Russell King - ARM Linux admin Subject: Re: Memory size and section boundary on armv7 Message-ID: <20190412101013.GA3772@apalos> References: <20190411151320.GA23031@apalos> <20190411154129.xh5eoicmjkpt6ceb@shell.armlinux.org.uk> <20190411155000.GA25323@apalos> <20190411162210.462hwmwlwrciq3re@shell.armlinux.org.uk> <20190412052344.GA13530@apalos> <20190412084049.k34n22poz2vz7kn7@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190412084049.k34n22poz2vz7kn7@shell.armlinux.org.uk> User-Agent: Mutt/1.5.24 (2015-08-30) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190412_031018_489201_FBEC88BF X-CRM114-Status: GOOD ( 29.76 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: catalin.marinas@arm.com, labbott@redhat.com, linux-arm-kernel@lists.infradead.org, ard.biesheuvel@linaro.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Russell, > > > > > > arch/arm/include/asm/pgtable-2level.h documents how we fit the > > > hardware's page table implementation to the kernel's page table > > > requirements. The key thing to note is that, because of the mismatch > > > between the kernel and the hardware, a Linux page table occupies two > > > physical level 1 entries, whereas a section occupies one level 1 > > > entry. > > > > > Yes i read that. Maybe i'll get a better hang of it after more reads > > > > > Hence, if there is a section mapping in the even-numbered level 1 > > > entry, and we then get a request via alloc_init_pte() to create a > > > page table, we can't without destroying the mapping that is already > > > present. > > > > > This is exactly what's happening. > > [ 0.000000] __map_init_section addr: c0200000, next c0300000, phys c0200000 len 100000 > > [ 0.000000] __map_init_section addr: c0300000, next c0400000, phys c0300000 len 100000 > > > > These are 2 subsequent section mappings that work. If there's any memory marked > > as MEMBLOCK_NOMAP in the second section though the code path is > > alloc_init_pte(). Should't we just skip that section overall ? > > We can't skip the section mapping - if we skip the first section, > when the kerenl then tries to access memory in that section, the > kernel will oops. We also have no prior knowledge in the mapping > functions that this situation will occur. Thanks for the explanation. > > > > I am not sure i am following here. Since we can detect that why allow > > firmware implementations crash the kernel? (as long as the memory > > mappings are not wrong or overlapping) > > It evolution. These firmware implementations have come along _way_ > after the ARM mapping code was written, and they construct various > situations that are difficult to handle - and given the further > evolution of the kernel with facilities such as the NX protections > (which rely on eg, the kernel text, being aligned to section > boundaries so that different permissions can be given to each section, > it is impossible to see any way to solve this problem at the mapping > code level. Can we at least we can print a warning saying "What you are trying to do is not good enough, please re-check the mappings" or something like that, to help people avoid that in the future. The BUG_ON is supposed to do that, but for some reason i can't see it on my console, any ideas why? > > All my tests were with memblock and efi debug enabled. I just left them out, my > > bad. > > > > Here's the tests and working vs non working use-cases > > On all cases FDT size = 0xc000 > > > > ## fdt memory marked as MEMBLOCK_NOMAP. FDT at c7f00000 ## > > > > [ 0.000000] MEMBLOCK configuration: > > [ 0.000000] memory size = 0x20000000 reserved size = 0x00000000 > > [ 0.000000] memory.cnt = 0x1 > > [ 0.000000] memory[0x0] [0xc0000000-0xdfffffff], 0x20000000 bytes flags: 0x0 > > [ 0.000000] reserved.cnt = 0x1 > > [ 0.000000] reserved[0x0] [0x00000000-0xffffffff], 0x00000000 bytes flags: 0x0 > > [ 0.000000] memblock_remove: [0x00000000-0xfffffffe] reserve_regions+0x64/0x220 > > [ 0.000000] memblock_add: [0xc0000000-0xc1ffffff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xc2000000-0xc2860fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xc2861000-0xc7cfffff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xc7d00000-0xc7efffff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xc7f00000-0xc7f0bfff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xc7f0c000-0xdc705fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdc706000-0xdc709fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdc70a000-0xdcf6afff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdcf6b000-0xdcf6bfff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdcf6c000-0xdcf72fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdcf73000-0xdcf73fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdcf74000-0xdcf75fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdcf76000-0xdff80fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdff81000-0xdff81fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdff82000-0xdfffffff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_reserve: [0xdc706000-0xdc706fff] efi_init+0xe4/0x1c4 > > [ 0.000000] memblock_reserve: [0xc0300000-0xc18f7ad7] arm_memblock_init+0x30/0x168 > > [ 0.000000] memblock_reserve: [0xc0204000-0xc0207fff] arm_memblock_init+0x108/0x168 > > [ 0.000000] memblock_reserve: [0xc7d00000-0xc7d0896c] arm_memblock_init+0x11c/0x168 > > [ 0.000000] memblock_reserve: [0xd8000000-0xdbffffff] memblock_alloc_range+0x54/0x6c > > [ 0.000000] cma: Reserved 64 MiB at 0xd8000000 > > [ 0.000000] MEMBLOCK configuration: > > [ 0.000000] memory size = 0x20000000 reserved size = 0x05605445 > > [ 0.000000] memory.cnt = 0x7 > > [ 0.000000] memory[0x0] [0xc0000000-0xc7efffff], 0x07f00000 bytes flags: 0x0 > > [ 0.000000] memory[0x1] [0xc7f00000-0xc7f0bfff], 0x0000c000 bytes flags: 0x4 > > [ 0.000000] memory[0x2] [0xc7f0c000-0xdcf6afff], 0x1505f000 bytes flags: 0x0 > > [ 0.000000] memory[0x3] [0xdcf6b000-0xdcf75fff], 0x0000b000 bytes flags: 0x4 > > [ 0.000000] memory[0x4] [0xdcf76000-0xdff80fff], 0x0300b000 bytes flags: 0x0 > > [ 0.000000] memory[0x5] [0xdff81000-0xdff81fff], 0x00001000 bytes flags: 0x4 > > [ 0.000000] memory[0x6] [0xdff82000-0xdfffffff], 0x0007e000 bytes flags: 0x0 > > [ 0.000000] reserved.cnt = 0x5 > > [ 0.000000] reserved[0x0] [0xc0204000-0xc0207fff], 0x00004000 bytes flags: 0x0 > > [ 0.000000] reserved[0x1] [0xc0300000-0xc18f7ad7], 0x015f7ad8 bytes flags: 0x0 > > [ 0.000000] reserved[0x2] [0xc7d00000-0xc7d0896c], 0x0000896d bytes flags: 0x0 > > [ 0.000000] reserved[0x3] [0xd8000000-0xdbffffff], 0x04000000 bytes flags: 0x0 > > [ 0.000000] reserved[0x4] [0xdc706000-0xdc706fff], 0x00001000 bytes flags: 0x0 > > > > # Extra debug > > [ 0.000000] __map_init_section addr: c7c00000, next c7e00000, phys c7c00000 len 200000 c7c1141e > > [ 0.000000] __map_init_section addr: c7e00000, next c7f00000, phys c7e00000 len 100000 c7e1141e > > [ 0.000000] alloc_init_pte addr: c7f0c000, next c8000000, len f4000 pmd: c7e1141e > > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc3-29427-g769f1f8f9b56-dirty #152 > > [ 0.000000] Hardware name: STM32 (Device Tree Support) > > [ 0.000000] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > > [ 0.000000] [] (show_stack) from [] (dump_stack+0x8c/0xa0) > > [ 0.000000] [] (dump_stack) from [] (arm_pte_alloc+0x58/0x80) > > [ 0.000000] [] (arm_pte_alloc) from [] (__create_mapping+0x2f4/0x34c) > > [ 0.000000] [] (__create_mapping) from [] (paging_init+0x234/0x648) > > [ 0.000000] [] (paging_init) from [] (setup_arch+0x660/0xcac) > > [ 0.000000] [] (setup_arch) from [] (start_kernel+0x70/0x458) > > [ 0.000000] [] (start_kernel) from [<00000000>] ( (null)) > > > > So the kernel correctly skips the 0xc000 that u-boot marked as NOMAP, > > but then crashes. > > If that is the FDT, why is it being marked NOMAP? The kernel needs it > to be mapped (but marked reserved in memblock) so that it can access > it. When booting normally with u-boot, FDT is not marked NOMAP. The u-boot code marks it as EFI_RUNTIME_SERVICES_DATA, so they get flagged as NOMAP. There's a parallel u-boot discussion on this trying to figure out if that's correct > > > The pmd value here is the same for the 1mb of mapped by __map_init_section() and > > for the subsequent alloc_init_pte(). Should we just skip that? > > > > ## fdt memory marked as MEMBLOCK_NOMAP. FDT at c7eff000 ## > > [ 0.000000] MEMBLOCK configuration: > > [ 0.000000] memory size = 0x20000000 reserved size = 0x00000000 > > [ 0.000000] memory.cnt = 0x1 > > [ 0.000000] memory[0x0] [0xc0000000-0xdfffffff], 0x20000000 bytes flags: 0x0 > > [ 0.000000] reserved.cnt = 0x1 > > [ 0.000000] reserved[0x0] [0x00000000-0xffffffff], 0x00000000 bytes flags: 0x0 > > [ 0.000000] memblock_remove: [0x00000000-0xfffffffe] reserve_regions+0x64/0x220 > > [ 0.000000] memblock_add: [0xc0000000-0xc1ffffff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xc2000000-0xc2860fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xc2861000-0xc7cfefff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xc7cff000-0xc7efefff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xc7eff000-0xc7f0afff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xc7f0b000-0xdc705fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdc706000-0xdc709fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdc70a000-0xdcf6afff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdcf6b000-0xdcf6bfff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdcf6c000-0xdcf72fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdcf73000-0xdcf73fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdcf74000-0xdcf75fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdcf76000-0xdff80fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdff81000-0xdff81fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdff82000-0xdfffffff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_reserve: [0xdc706000-0xdc706fff] efi_init+0xe4/0x1c4 > > [ 0.000000] memblock_reserve: [0xc0300000-0xc18f7ad7] arm_memblock_init+0x30/0x168 > > [ 0.000000] memblock_reserve: [0xc0204000-0xc0207fff] arm_memblock_init+0x108/0x168 > > [ 0.000000] memblock_reserve: [0xc7cff000-0xc7d0796c] arm_memblock_init+0x11c/0x168 > > [ 0.000000] memblock_reserve: [0xd8000000-0xdbffffff] memblock_alloc_range+0x54/0x6c > > [ 0.000000] cma: Reserved 64 MiB at 0xd8000000 > > [ 0.000000] MEMBLOCK configuration: > > [ 0.000000] memory size = 0x20000000 reserved size = 0x05605445 > > [ 0.000000] memory.cnt = 0x7 > > [ 0.000000] memory[0x0] [0xc0000000-0xc7efefff], 0x07eff000 bytes flags: 0x0 > > [ 0.000000] memory[0x1] [0xc7eff000-0xc7f0afff], 0x0000c000 bytes flags: 0x4 > > [ 0.000000] memory[0x2] [0xc7f0b000-0xdcf6afff], 0x15060000 bytes flags: 0x0 > > [ 0.000000] memory[0x3] [0xdcf6b000-0xdcf75fff], 0x0000b000 bytes flags: 0x4 > > [ 0.000000] memory[0x4] [0xdcf76000-0xdff80fff], 0x0300b000 bytes flags: 0x0 > > [ 0.000000] memory[0x5] [0xdff81000-0xdff81fff], 0x00001000 bytes flags: 0x4 > > [ 0.000000] memory[0x6] [0xdff82000-0xdfffffff], 0x0007e000 bytes flags: 0x0 > > [ 0.000000] reserved.cnt = 0x5 > > [ 0.000000] reserved[0x0] [0xc0204000-0xc0207fff], 0x00004000 bytes flags: 0x0 > > [ 0.000000] reserved[0x1] [0xc0300000-0xc18f7ad7], 0x015f7ad8 bytes flags: 0x0 > > [ 0.000000] reserved[0x2] [0xc7cff000-0xc7d0796c], 0x0000896d bytes flags: 0x0 > > [ 0.000000] reserved[0x3] [0xd8000000-0xdbffffff], 0x04000000 bytes flags: 0x0 > > [ 0.000000] reserved[0x4] [0xdc706000-0xdc706fff], 0x00001000 bytes flags: 0x0 > > > > # Extra debug > > [ 0.000000] __map_init_section addr: c7c00000, next c7e00000, phys c7c00000 len 200000 c7c1141e > > [ 0.000000] __map_init_section addr: c7c00000, next c7e00000, phys c7c00000 len 200000 > > [ 0.000000] alloc_init_pte addr: c7e00000, next c7eff000, len ff000 > > [ 0.000000] alloc_init_pte addr: c7f0b000, next c8000000, len f5000 > > > > So moving the FDT out of section alignment seems to fix the problem > > Indeed, because both even-section and odd-sections can't be created, > and so are both created as page tables, which avoids the overlapping > mappings problem. > Yes. U-Boot wise we could fix that, by placing the dtb on a non section aligned boundary > > ## Booting with MEMBLOCK_NOMAP removed from FDT area. FDT at c7f00000 > > > > [ 0.000000] MEMBLOCK configuration: > > [ 0.000000] memory size = 0x20000000 reserved size = 0x00000000 > > [ 0.000000] memory.cnt = 0x1 > > [ 0.000000] memory[0x0] [0xc0000000-0xdfffffff], 0x20000000 bytes flags: 0x0 > > [ 0.000000] reserved.cnt = 0x1 > > [ 0.000000] reserved[0x0] [0x00000000-0xffffffff], 0x00000000 bytes flags: 0x0 > > [ 0.000000] memblock_remove: [0x00000000-0xfffffffe] reserve_regions+0x64/0x220 > > [ 0.000000] memblock_add: [0xc0000000-0xc1ffffff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xc2000000-0xc2860fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xc2861000-0xc7cfffff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xc7d00000-0xc7efffff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xc7f00000-0xc7f0bfff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xc7f0c000-0xdc705fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdc706000-0xdc709fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdc70a000-0xdcf6afff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdcf6b000-0xdcf6bfff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdcf6c000-0xdcf72fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdcf73000-0xdcf73fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdcf74000-0xdcf75fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdcf76000-0xdff80fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdff81000-0xdff81fff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_add: [0xdff82000-0xdfffffff] reserve_regions+0x178/0x220 > > [ 0.000000] memblock_reserve: [0xdc706000-0xdc706fff] efi_init+0xe4/0x1c4 > > [ 0.000000] memblock_reserve: [0xc0300000-0xc18f7ad7] arm_memblock_init+0x30/0x168 > > [ 0.000000] memblock_reserve: [0xc0204000-0xc0207fff] arm_memblock_init+0x108/0x168 > > [ 0.000000] memblock_reserve: [0xc7d00000-0xc7d0896c] arm_memblock_init+0x11c/0x168 > > [ 0.000000] memblock_reserve: [0xd8000000-0xdbffffff] memblock_alloc_range+0x54/0x6c > > [ 0.000000] cma: Reserved 64 MiB at 0xd8000000 > > [ 0.000000] MEMBLOCK configuration: > > [ 0.000000] memory size = 0x20000000 reserved size = 0x05605445 > > [ 0.000000] memory.cnt = 0x5 > > [ 0.000000] memory[0x0] [0xc0000000-0xdcf6afff], 0x1cf6b000 bytes flags: 0x0 > > [ 0.000000] memory[0x1] [0xdcf6b000-0xdcf75fff], 0x0000b000 bytes flags: 0x4 > > [ 0.000000] memory[0x2] [0xdcf76000-0xdff80fff], 0x0300b000 bytes flags: 0x0 > > [ 0.000000] memory[0x3] [0xdff81000-0xdff81fff], 0x00001000 bytes flags: 0x4 > > [ 0.000000] memory[0x4] [0xdff82000-0xdfffffff], 0x0007e000 bytes flags: 0x0 > > [ 0.000000] reserved.cnt = 0x5 > > [ 0.000000] reserved[0x0] [0xc0204000-0xc0207fff], 0x00004000 bytes flags: 0x0 > > [ 0.000000] reserved[0x1] [0xc0300000-0xc18f7ad7], 0x015f7ad8 bytes flags: 0x0 > > [ 0.000000] reserved[0x2] [0xc7d00000-0xc7d0896c], 0x0000896d bytes flags: 0x0 > > [ 0.000000] reserved[0x3] [0xd8000000-0xdbffffff], 0x04000000 bytes flags: 0x0 > > [ 0.000000] reserved[0x4] [0xdc706000-0xdc706fff], 0x00001000 bytes flags: 0x0 > > I don't see any sign of the FDT being reserved in memblock, which is > dangerous - the FDT could be overwritten during the early kernel boot. > This was more of a test to indicate that 'if we dont mark it as NOMAP, we dont crash' and provide further info for the analysis. Thanks for the note though, we'll make sure we won't overwrite those Thanks for taking the time with this. I still have some reading to fully understand the implications. The easiest way out of it is to place the fdt on !SECTION_SIZE right? Thanks /Ilias _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel