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=-3.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_NEOMUTT 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 7102EC10F0E for ; Fri, 12 Apr 2019 11:16:36 +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 427FF20643 for ; Fri, 12 Apr 2019 11:16:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="VK0CnsP9"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="iHzubTI2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 427FF20643 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk 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=GSnFUr2tPZ+3NzgemN975LScYZFX8Zshr9VmcAazM8A=; b=VK0CnsP9XxQVjj aecQuRG7OD/rzolqwWApjBXHutemkbGtePS1EJXRonIm/poiqdf8TcCha9y+qljIv64q6lT12LerT 7SUKwDIPGsQsrV6y8VV8Eu74NEXPmDDTYYeFLjxN1tp0wCReEZfVHz80xo2SWYq77CxpQT5oMVun7 cMzle9xMPZyvVH+PTscTvfSsf7a83aZq3x3JJ+hbsTsX5gBgzdm0V/pVGvm9cQKIMx0pH6bso9wi7 IWF8PGw2z3R0FkMyYOXKPqB1MmAqryvBVi9DgSTi4zVKNpNemhJRQyw0CFnpnefjazLsCzfsTtrSZ eoYy7yOOLv219nRqtYYg==; 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 1hEuAb-00066R-KU; Fri, 12 Apr 2019 11:16:33 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hEuAX-00065x-9g for linux-arm-kernel@lists.infradead.org; Fri, 12 Apr 2019 11:16:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rO9s1iofb+Ce/slXeTEq79+QV2pixVrWOd3LL+f15vw=; b=iHzubTI24cygIKS9bjVF9w2aw slASYSxZrW21Szcl8EmsLNjCmwNxjJk0NGnIy0gHbTnByIqnWKIMIBev104JQtHjTbGrCxa+tPdSI l4FkxDUtRe13+0CnE4aVCM2FUghqf5A+THIvOEQtghD9njwsnT35uNLRCcxf9GmoLurxTX6rrezno uN7C0BnGbIhZD4XOL5Bz+Sqin4kgFpOr7Wh2x8TcmeWOhDEv/oDZN6yXiwvw4JfU9WkCC7mbgDYFR 4IJXPL4KMLxzeaQRcd4h3d0acG08yxdNup/NT8NxjmthSSZpFVo7zImb6ib63G1gpbOx9/ykII/Gv od4lmYkkA==; Received: from shell.armlinux.org.uk ([2002:4e20:1eda:1:5054:ff:fe00:4ec]:37730) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hEuAQ-0000YV-Cj; Fri, 12 Apr 2019 12:16:22 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.89) (envelope-from ) id 1hEuAJ-0004p9-4q; Fri, 12 Apr 2019 12:16:15 +0100 Date: Fri, 12 Apr 2019 12:16:15 +0100 From: Russell King - ARM Linux admin To: Ilias Apalodimas Subject: Re: Memory size and section boundary on armv7 Message-ID: <20190412111614.xbwnffum25ny7ddy@shell.armlinux.org.uk> 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> <20190412101013.GA3772@apalos> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190412101013.GA3772@apalos> User-Agent: NeoMutt/20170113 (1.7.2) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190412_041629_826579_66E31E29 X-CRM114-Status: GOOD ( 34.37 ) 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 On Fri, Apr 12, 2019 at 01:10:13PM +0300, Ilias Apalodimas wrote: > 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? That may be a possibility, we would have to ignore the request to setup the mapping, which means we could end silently locking up shortly there-after. It may also be possible to slightly rearrange the code to map the vectors page before we setup any of the memory mappings (so that exceptions can work), but that may need careful handling. > > > 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 That's actually misleading. The problem happens when you have a small no-map section within a 2MB region, and it doesn't cross the even-odd 1MB boundary. To illustrate what I'm saying, if you arranged for it to be (eg) one page higher (iow, 0xc7f01000) then you'll hit the same problem. > > > ## 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? See above, that's not entirely accurate. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel