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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 4223DC433E1 for ; Sat, 15 Aug 2020 08:30:25 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 0989B23102 for ; Sat, 15 Aug 2020 08:30:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="SveCO5Rr"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Oi8jQAgD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0989B23102 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:Date:To:From:Subject:References: In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=cTYkABwXCXEKaRWlDHAjpONTRGWXPTj77wyXDDdafHg=; b=SveCO5Rre3LpCskNG9eUcUZtf VOSLROpxSkCxx/lgX/cGTPhB4akVdJnfByLXLFGocdZkKamKTgI65iAZVq9v6kNlTeGPtV0PgPz4Q ajuodaq1A65cpB+c6REmqpatg49V61WuBMGq5Tvznw0804AO54N2kyTb0dX3EgNIPWPpGXp7ADxNh 17IRodryTKb3vSiBg41hRKI3BBoMrzpbUjE/FKPi+0DK+S1lx0E+WuNi7Tf2lKjfoQGWfOsoaD1cq uh/yLfUcrUrDeONHDewd8FnMkWRP+h4U2mYzuLVrk1iviJcHOFs3or5l2QinqpbJp5V63Xb3L91IS TXukFkCuw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k6rYO-00025O-Pi; Sat, 15 Aug 2020 08:28:40 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k6rYM-000254-1r for linux-arm-kernel@lists.infradead.org; Sat, 15 Aug 2020 08:28:39 +0000 Received: from kernel.org (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 429BA23108; Sat, 15 Aug 2020 08:28:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597480116; bh=Z3oTPFBH7Zb9AZuALkPSF1LZViQyorhxRNBNNgUWqQE=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=Oi8jQAgDvW+iprM6Q97dmaO0wx7qP/Qg3srqKxDnhNccEAU06dQem8ScG7XNclTGp jODyxpbbNP8xoDlG17/+w28J8u0ukfTifIZHjYj5Z0HR5b7ekI1ZBYtTLt4DB+D+Z6 E0vWLoPaPHYyvE7krNXcIW20UVee4qLBjhTnXLV8= MIME-Version: 1.0 In-Reply-To: References: <20200706150205.22053-1-geert+renesas@glider.be> <159546718359.3847286.13460778905630969897@swboyd.mtv.corp.google.com> Subject: Re: [PATCH/RFC v7] ARM: boot: Obtain start of physical memory from DTB From: Stephen Boyd To: Linus Walleij Date: Sat, 15 Aug 2020 01:28:35 -0700 Message-ID: <159748011515.33733.12886780037889852900@swboyd.mtv.corp.google.com> User-Agent: alot/0.9.1 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200815_042838_335867_7F48FAAF X-CRM114-Status: GOOD ( 28.38 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kumar Gala , Arnd Bergmann , Geert Uytterhoeven , Nicolas Pitre , Masahiro Yamada , Lukasz Stelmach , Russell King , Bjorn Andersson , Linux-Renesas , Chris Brandt , Uwe =?utf-8?q?Kleine-K=C3=B6nig?= , Eric Miao , Dmitry Osipenko , Laura Abbott , Ard Biesheuvel , Linux ARM , Marek Szyprowski Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Quoting Linus Walleij (2020-08-14 07:03:41) > On Thu, Jul 23, 2020 at 3:19 AM Stephen Boyd wrote: > > > > > textofs-$(CONFIG_ARCH_IPQ40XX) := 0x00208000 > > > > textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000 > > > > textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000 > > > > > > But what on earth is this? I just deleted this and the platform > > > boots just as well. > > > > We need to shift the kernel text to start 2MB beyond the start of memory > > because there is the shared memory region used to communicate with other > > processors in the SoC there. It took a while for us to convince other OS > > folks in the company to put shared memory somewhere else besides the > > start of RAM, but eventually we won that battle. > > > > Does your booted kernel have its text section at the start of RAM or is > > it offset by 2MB without this change? Check out /proc/iomem to see where > > the kernel text is in relation to the start of RAM. > > The memory on this machine starts at 0x40200000 since the effect > of the current code is to take pc &= 0xf8000000 and that results in > 0x40000000 and then this adds textofs 0x00208000 to that > resulting in 0x40208000 for the kernel physical RAM. Which > is what we want to achieve since the RAM starts at > 0x40200000. The bootloader is telling the kernel that memory starts at 0x40200000 but in reality RAM or DDR starts at 0x40000000 and the first 2MB are reserved for shared memory. In the old days the bootloader would remove the shared memory region from the memory layout and update ATAGs to indicate that memory started at 0x40200000. > > But TEXT_OFFSET is also used inside the kernel to offset the > virtual memory. This means that when we set up the virtual > memory split, the kernel virtual memory is also bumped by > these 2 MB so the virtual memory starts at 0xC0208000 > instead of 0xC0008000 as is normal. > > It looks weird to me but maybe someone can explain how > logical that is? Yes, that's intentional. I believe that's because it will map the first 2MB of memmory otherwise with the wrong attributes. The kernel needs to map shared memory as non-cacheable or something like that so that communication to the modem isn't going through the cache and needing constant cleaning. Hope it helps! If not, we can probably dig up mailing list discussions on this. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel