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.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 6516DC433DF for ; Tue, 7 Jul 2020 08:00:19 +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 330E62063A for ; Tue, 7 Jul 2020 08:00:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="KyLvM306" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 330E62063A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=FZIR55mpV75+pefUU7qJfz5qMe3RpCqDGUsU7XSkpvU=; b=KyLvM306+lTJXivRAwOWI5k/Q jnQUDGo5angDVd8gW5GMr/CchL3VWkCy7IVEuDoZiKzo0zvNJ1zSVDFp3JTlRNOUWcG90lZRCdhLK FJgN1fWDiROmLYf1wCi57gYzl+FBuDw0zKUfdRMTjiAjRzz69//kHO6Y+tbbc8KDzz2wVKg8JzNhd 8MVglK6NdHe4OC8yIIjZTasHiuxkwnJUE/3s4bA2HxFw/ByXczvvaTO+FXQRnkJnvVFQRwBjPjqIg 5+JuXkV9zFji0xA7R4EsA5lD+TW/IAeHbKzBPd4TeiIIBjn8Tjlxz+S3yq3p/phLH2iU/eqi1IIB0 NjerD5qwA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jsiV9-0006dn-4E; Tue, 07 Jul 2020 07:58:51 +0000 Received: from mail-oi1-f195.google.com ([209.85.167.195]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jsiV5-0006dP-Qu for linux-arm-kernel@lists.infradead.org; Tue, 07 Jul 2020 07:58:48 +0000 Received: by mail-oi1-f195.google.com with SMTP id y22so21577730oie.8 for ; Tue, 07 Jul 2020 00:58:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gM5eD64lpfuDctEPr4G1NsrcEzEVkWdUqeZEr3N96yc=; b=Upb3xRS9hQz40xLLtDtpZWkuVzSg1ozs5sF62Uwr3+GjFS785ZlhHiis1XlBReDHRz gNl7Bzmwz32rMAQIjJCsZ/CISWUoZMzfFmMz/fDPAfe+gqAIAtBJyp1+hcCEgUo2o1j1 ppVS9/iE+mJ0KmRSmH/vpkVsdiZs0gsRcmKM6qxBEpNwDGkNf9x8P9ZOYip81uNPf0lH JJNxuqJTOpkXIsYEk6W+P4lBaul86GgYlEc74thFY1CLH9QgrlsURVUzja5Ua85GO5mh zEYkEfCKbSF82+F2UJ3+VsQVGePML4aHsXmYwDXvGSkRvXU/yO8k1GY6A+COGPin2dyJ UoaQ== X-Gm-Message-State: AOAM533uI1OgEE7bkkdAvJ3wMbYLlRiDCy03t3in751NL3Z3jcpQqB37 nkiKyaXNbQxkgkrXmP4IxxVUBXY5EPTCBR2aPAQ3wVua7KU= X-Google-Smtp-Source: ABdhPJyPhCwHw+BH5hWBP7RH7D6H/uIBwF1q9JsFmjpKP2IF5Ov3qprM33CsK/VA2lnkZtTHEiVg5CJSaiRKRF49UCw= X-Received: by 2002:aca:5c41:: with SMTP id q62mr2261847oib.148.1594108727033; Tue, 07 Jul 2020 00:58:47 -0700 (PDT) MIME-Version: 1.0 References: <20200706150205.22053-1-geert+renesas@glider.be> In-Reply-To: From: Geert Uytterhoeven Date: Tue, 7 Jul 2020 09:58:35 +0200 Message-ID: Subject: Re: [PATCH/RFC v7] ARM: boot: Obtain start of physical memory from DTB To: Ard Biesheuvel X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200707_035847_913377_6C158EC6 X-CRM114-Status: GOOD ( 27.00 ) 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: Arnd Bergmann , Nicolas Pitre , Masahiro Yamada , Lukasz Stelmach , Russell King , Linux-Renesas , Chris Brandt , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Eric Miao , Dmitry Osipenko , 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 Hi Ard, On Tue, Jul 7, 2020 at 9:45 AM Ard Biesheuvel wrote: > On Tue, 7 Jul 2020 at 10:39, Geert Uytterhoeven wrote: > > On Tue, Jul 7, 2020 at 8:50 AM Ard Biesheuvel wrote: > > > On Mon, 6 Jul 2020 at 18:02, Geert Uytterhoeven wrote: > > > > Currently, the start address of physical memory is obtained by masking > > > > the program counter with a fixed mask of 0xf8000000. This mask value > > > > was chosen as a balance between the requirements of different platforms. > > > > However, this does require that the start address of physical memory is > > > > a multiple of 128 MiB, precluding booting Linux on platforms where this > > > > requirement is not fulfilled. > > > > > > > > Fix this limitation by obtaining the start address from the DTB instead, > > > > if available (either explicitly passed, or appended to the kernel). > > > > Fall back to the traditional method when needed. > > > > > > > > This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM > > > > on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space), > > > > i.e. not at a multiple of 128 MiB. > > > > > > > > Suggested-by: Nicolas Pitre > > > > Signed-off-by: Geert Uytterhoeven > > > > Reviewed-by: Nicolas Pitre > > > > Reviewed-by: Ard Biesheuvel > > > > Tested-by: Marek Szyprowski > > > > Tested-by: Dmitry Osipenko > > > > Cc: Lukasz Stelmach > > > > --- > > > > Marked as RFC, because: > > > > 1. This is known to break crashkernel support, as the memory used by > > > > the crashkernel is not marked reserved in DT (yet), > > > > 2. Russell won't apply this for v5.9 anyway, > > > > > > > > > > Would it help if we make this behavior dependent on a simple heuristic, e.g., > > > > > > if (round_up(load_address, 128M) >= dram_end) > > > use dram_start from DT > > > else > > > use round_up(load_address, 128M) > > > > > > That way, the fix is guaranteed to only take effect for systems that > > > cannot even boot otherwise, which fixes the crashkernel case, as well > > > as other potential regressions due to the load address of the core > > > kernel changing for existing boards. > > > > Thanks for your suggestion! > > 1. Shouldn't the calculation use round_down() instead of round_up()? > > 2. Likewise, "round_down(load_address, 128M) < dram_start from DT"? > > > > No. > > What the code does today is round *up* to a multiple of 128 MB, and > only when that leads to a problem, we should use the DT provided > memory regions. mov r4, pc and r4, r4, #0xf8000000 Surely this is rounding down, isn't it? add r4, r4, #TEXT_OFFSET Followed by adding a small number (typically 0x00008000). On RZA2MEVB with 64 MiB of RAM, the result lies below dram_start. BTW, how to obtain dram_end? From DT again? Do we trust it, as we apparently cannot trust dram_start in some configurations. Do I need more coffee? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel