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 A9F3AC10F0E for ; Fri, 12 Apr 2019 05:23:56 +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 6E4CF2086D for ; Fri, 12 Apr 2019 05:23:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="rEz52Lke"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="W5AcFpif" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6E4CF2086D 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=n2t48H5LO3cqVNM8/sUNNTyOJkJBz0hOC2D1oWy6C1w=; b=rEz52Lkeif13lU gHqmxp8BSiegCXDUFTGbM93YKUBIauf1Vu5G9HVfeDAUkqbt53sEKRaHIOO48eJaB4MhqTU7KoOFP qXjCjLwonq0sp5/roOivpz3Q2ccJVn5c9QWDJWdBu4r5Qlx8irRU2bz3QZSIo9jCQybGu/lIMwcQg drfefgGWAb88cjF2zTFqVuIitktXp+lcRsoluVKvgr1V+txRk+wEZkTrREbScb/xRpKA5iVKwhhJ6 JwMaTT3Z0TnffxnKp7weUT1+cmjXErXui0LgNKTU7UDVnalD7H/SWDF/a72EcxqKx/E1UInVHOwOv 05CZastSEKikgnYqWiPA==; 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 1hEofK-0007Hs-IO; Fri, 12 Apr 2019 05:23:54 +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 1hEofH-0007HQ-8b for linux-arm-kernel@lists.infradead.org; Fri, 12 Apr 2019 05:23:53 +0000 Received: by mail-wm1-x343.google.com with SMTP id 4so9528527wmf.1 for ; Thu, 11 Apr 2019 22:23:50 -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=QqDGzHu5b9Tfc/q6mIfxqlSxDXAT3Y/cOCYDHbg+dHQ=; b=W5AcFpif+IxBFeEabIGMmsu61kK1BoOa+5PC3h9a82r56Ti0uV5Ec1/nHkM6f1zClz F2XpVJifpKC2ZC0beqFAOCkgmF43MWkYAuKS5HWiaBQD92GT+B97R3iJB3cqwKqseQz5 8wN5WchD5GqJ6pYAIjYpDW8WHFRBPZ27ia67L97YhgCy0/pCtBC5G9NXVh1DKK/cpZ6e wYVKRdHKn2aE9VFxYuxXqcY5863lNt/vdJLb7uVlGDnpkJyozRp0I0Lw4OWRo2KNv72x MlG+qFsUiltnCRU5y6czjZZdoHuV966wF3Qdh8enxOjllUZfme1JzqzL1+cazPfoK25v h6DQ== 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=QqDGzHu5b9Tfc/q6mIfxqlSxDXAT3Y/cOCYDHbg+dHQ=; b=UnhcMA98Q9vhZX8NqjJbISmfne6mCX7ef/csRk7jfgXZnAcUrf3UIXTJncZfAHpDuy 3QGfBOYFwQ6sNjA2zSVMBgYhmlwFXVYcOiDFZ5hkV3JHwi9XamB45FlfBnwvq9fSnFdE RS8GQg6Ku3iFydqMNhd6fOklvnoc1/yXZ/ZKK5KNWPPvK4H1QfNFFFgq1QhkT29IdFHK n5grxXS3+JiRKBUKy+p2JL9j1Kmstmlj0UA5h3BKHFXPB6dz39kTTNp7h4PTqrym0E98 3s55+2LPChg81LXrqOkf5v6f0J2sHG2eG96sEAofnUvhMM10854uZT7M3s+vwE+GNeKG KWuA== X-Gm-Message-State: APjAAAWP8eFSDdyulvuoY1N596llcUIW31u8zl4RZIgt8ST3TmrO087x ZbTXHkUbqPfPT2+kXYOGM/R7Vg== X-Google-Smtp-Source: APXvYqw/LT0jlY9T5k1LNsL4CMAQOIIO+eLNvPFTC2ja+fW5XmNRy1IF8Mg9QJPurQgGgfRp3QITAQ== X-Received: by 2002:a1c:a8d3:: with SMTP id r202mr9693933wme.106.1555046628596; Thu, 11 Apr 2019 22:23:48 -0700 (PDT) Received: from apalos (athedsl-165181.home.otenet.gr. [85.75.188.219]) by smtp.gmail.com with ESMTPSA id n11sm65684683wrt.63.2019.04.11.22.23.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 22:23:47 -0700 (PDT) Date: Fri, 12 Apr 2019 08:23:44 +0300 From: Ilias Apalodimas To: Russell King - ARM Linux admin Subject: Re: Memory size and section boundary on armv7 Message-ID: <20190412052344.GA13530@apalos> References: <20190411151320.GA23031@apalos> <20190411154129.xh5eoicmjkpt6ceb@shell.armlinux.org.uk> <20190411155000.GA25323@apalos> <20190411162210.462hwmwlwrciq3re@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190411162210.462hwmwlwrciq3re@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-20190411_222351_338867_60C42A00 X-CRM114-Status: GOOD ( 36.42 ) 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, > > > It seems that alloc_init_pte() is finding that a section mapping has > > > already been created for the virtual address range, but it is then > > > being asked to create a page table mapping over the top of it. That > > > is one BIG no no. Replacing the existing section mapping with a page > > > table means that the section mapping is destroyed. If we allowed > > > such replacement, when the section mapping is accessed, we will end > > > up oopsing the kernel. > > > > On the crashing case calling __map_init_section() maps 1mb should the rest be > > skipped then? > > Sorry, I don't understand the question. What "rest" are you referring > to? I'll try to explain this better on my test-cases below > > > It is also designed to allow hardware-section sized mappings (making > > > it possible to map sections on 1MB granularity) but as a single Linux > > > page table always occupies 2MB, it is not permitted for the unused > > > half of an aligned 2MB slot to be used for a page table mapping - > > > hence this BUG_ON(). > > > > > > The ARM early mapping routines are intentionally designed such that > > > areas of memory that they are asked to map are non-overlapping - it > > > is the caller's responsibility to ensure this. > > > > And the case i described falls into 'overlapping'? > > Yes, as I described above - note that I pointed out that a page table > takes a naturally aligned 2MB of space, and sections are naturally > aligned 1MB of space. > > 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 ? > So, yes, this absolutely is an overlapping mapping. It may not be > at page level, but it is in exactly the same way as asking for the > first half of a page to be mapped to one physical address, and the > second half to be mapped to a different physical address would be - > that is beyond the capabilities of the system to achieve. > > Having a section mapping in the first 1MB of a 2MB block and then > trying to create a page table in the second half of a 2MB block is > illegal as, as far as Linux is concerned, the level 1 page table > is indexed in 2MB chunks and contains 2048 entries, not 4096 that > the hardware actually has. Thanks for the explanation. > > In fact, the software implementation completely ignores the odd- > numbered entries in the L1 page table beyond writing them. > > > > > > > So, this is not a problem with the mapping functions, but the way they > > > are being used. 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) > > > Beyond that, it is impossible to say with the above information since: > > > > > > 1. You've obviously added some additional printk()s, but you haven't > > > said where they are or what they mean. What is the difference > > > between "MAP addr" and "INI addr" ? > > MAP comes from alloc_init_pmd() when calling () > > INI comes from the same function when calling alloc_init_pte() > > > > > > 2. You haven't included the text of the crash, so there's no way to > > > know the call path to the BUG_ON(), and hence ascertain where the > > > duplicated mapping is coming from. > > > > > > Please always provide the full unaltered text from any kernel oops, bug > > > or warning. > > That's because the BUG_ON never shows up in my console. I added printks before > > and after the BUG_ON() though and i can only see the first print > > I can provide a dump_stack() if that helps. > > Yes please. > > It may also help to enable memblock debugging (memblock=debug) so we can > see what that looks like as well. 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. 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 ## 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 # Extra debug(The FDT is mapped here instead of skipped) [ 0.000000] __map_init_section addr: c7e00000, next c8000000, phys c7e00000 len 200000 Also if i force the FDT size to 1MB i obviously skip the offending region and boot correctly. Thanks /Ilias _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel