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.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 494BEC433DF for ; Tue, 7 Jul 2020 08:40:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 25E9D2053B for ; Tue, 7 Jul 2020 08:40:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594111219; bh=RxMiDqX6dWtkGkx98kCwff2deKll0yGeaYuz49mtyfo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=MJ2hHrjBk0L874c5sbu83SG4FRyMbXWrgVBAHw0N7RBUZm2QHGWwtVFnRtehnE70j ZJoM2cpyrcVpitehyhTf+m2ZP0drHQfgSkOVq3FerXsApD2CsBVemCBSiS6NKB8cbp 1Pks0HwT26fbFlapmio0GbEcXtt5sKe7ne39H72E= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726883AbgGGIkT (ORCPT ); Tue, 7 Jul 2020 04:40:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:34736 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725825AbgGGIkS (ORCPT ); Tue, 7 Jul 2020 04:40:18 -0400 Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 05834206F6 for ; Tue, 7 Jul 2020 08:40:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594111218; bh=RxMiDqX6dWtkGkx98kCwff2deKll0yGeaYuz49mtyfo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=k4Dp3qmrr22ZztowBAzyLkiXfXFMSokHj6Ov0QgvCtgghblF47bQOOLX4RRqgNkOn gQdOeZOfmfqrcvPGl+4mHwE96QtBcGJeRMVdJOVsgWieEzm1n4LK82LKShfiCCphol ZShqnqhl9P0m8QStriHAF3SuAsMiqto/V4hB34rs= Received: by mail-ot1-f52.google.com with SMTP id 95so23116695otw.10 for ; Tue, 07 Jul 2020 01:40:17 -0700 (PDT) X-Gm-Message-State: AOAM530OjnaFd3Nj20/OKpnHq5nHVGZAlfxXK2XYFTLq5VkDp8od6A7k K1+I99456V1XQaRjMI8Pjnhx9p3fZt/ew6oRJo0= X-Google-Smtp-Source: ABdhPJzfzTnHVb1JHiKBtdiSn8grRwJgm9yvfo4tYHhbikDHnh95c0JxJJMWymGFbX/KV5geyclEYFYhGKgVl0gz47U= X-Received: by 2002:a9d:4a8f:: with SMTP id i15mr47646336otf.77.1594111217314; Tue, 07 Jul 2020 01:40:17 -0700 (PDT) MIME-Version: 1.0 References: <20200706150205.22053-1-geert+renesas@glider.be> In-Reply-To: From: Ard Biesheuvel Date: Tue, 7 Jul 2020 11:40:06 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH/RFC v7] ARM: boot: Obtain start of physical memory from DTB To: Geert Uytterhoeven Cc: Dmitry Osipenko , Nicolas Pitre , Arnd Bergmann , Eric Miao , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Lukasz Stelmach , Russell King , Masahiro Yamada , Marek Szyprowski , Chris Brandt , Linux ARM , Linux-Renesas Content-Type: text/plain; charset="UTF-8" Sender: linux-renesas-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-renesas-soc@vger.kernel.org On Tue, 7 Jul 2020 at 11:35, Ard Biesheuvel wrote: > > On Tue, 7 Jul 2020 at 10:58, Geert Uytterhoeven wrote: > > > > 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? > > > > Yes you are right. > > > 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. > > Yes, but in the general case, this is not true. Platforms that manage > to boot using the current arrangement will do so by putting the > decompressor above the first 128 MB aligned boundary covered by DRAM > (and lose access to any memory below it via the linear mapping, but > this memory could still be used via a no-map reserved-memory node > AFAIK.) > > > 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? > > > > Maybe we both do :-) > > AIUI, the reason we cannot trust dram_start is because of the > crashkernel case, i.e., the kernel may have deliberately been put high > up in memory, and the expectation is that the load address is derived > by rounding down the load address of the decompressor. > > Hence my suggestion to round *up* and compare with dram_end: if > round_up(load_address, 128M) >= dram_end holds, it is guaranteed that > no address exists in memory from which we could round down and arrive > at a valid DRAM address. This would mean that your change will only > affect platforms that were unable to boot to begin with, and not > affect any other weird configurations including crashkernels etc Uhm maybe not ... Time to get that coffee... 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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 ABEA6C433E0 for ; Tue, 7 Jul 2020 08:41:52 +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 77E782053B for ; Tue, 7 Jul 2020 08:41:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="qxCs9kpW"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="k4Dp3qmr" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 77E782053B 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: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=nVx74zof3lZc1Iz7PFCGc1YDRej7Y9ixTSZeWVmNnVg=; b=qxCs9kpWPAr/ATgNk6dCgAxy6 a5jLIKV14hYiZRRHr0TcWT+pSMO5fGNAEaOZkWjRVCnoe7jHJQwFoBjbqZRWrHTrVIbI9lYr4TmTd rbYzsaVX8ngtCOuHdi2ZjdsmzyPcm92j6TAe2uQAn42G7Jc+c228ZeX4zAuT5B1oiMdpb610ch0LD u2CaiIqJofE9+VPOnfszgQLCGhrGMry9qpwtOpnBsN66sFmf3XBDUvmBfjlcwZnRWKzieCGiwR8Kr bixuyGRAm0T6Mgb1oSDXxwWvuiRfMS4yfLQLWhSdruAjmL19VV9vw4CEZV48pz8/z2ZhW9q329QVX 5xhA9hGQQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jsj9K-0002uc-E5; Tue, 07 Jul 2020 08:40:22 +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 1jsj9G-0002uF-SP for linux-arm-kernel@lists.infradead.org; Tue, 07 Jul 2020 08:40:19 +0000 Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0E83220708 for ; Tue, 7 Jul 2020 08:40:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594111218; bh=RxMiDqX6dWtkGkx98kCwff2deKll0yGeaYuz49mtyfo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=k4Dp3qmrr22ZztowBAzyLkiXfXFMSokHj6Ov0QgvCtgghblF47bQOOLX4RRqgNkOn gQdOeZOfmfqrcvPGl+4mHwE96QtBcGJeRMVdJOVsgWieEzm1n4LK82LKShfiCCphol ZShqnqhl9P0m8QStriHAF3SuAsMiqto/V4hB34rs= Received: by mail-ot1-f44.google.com with SMTP id c25so16130435otf.7 for ; Tue, 07 Jul 2020 01:40:18 -0700 (PDT) X-Gm-Message-State: AOAM532XfFpiSnTbGCZmUWlisZjobKZSD5qqBTgMTvVxQi1cD75nEGlY Q/59W2MJhW6ZzeyzfYFlgUM4ZHfM6tVJCflDEVQ= X-Google-Smtp-Source: ABdhPJzfzTnHVb1JHiKBtdiSn8grRwJgm9yvfo4tYHhbikDHnh95c0JxJJMWymGFbX/KV5geyclEYFYhGKgVl0gz47U= X-Received: by 2002:a9d:4a8f:: with SMTP id i15mr47646336otf.77.1594111217314; Tue, 07 Jul 2020 01:40:17 -0700 (PDT) MIME-Version: 1.0 References: <20200706150205.22053-1-geert+renesas@glider.be> In-Reply-To: From: Ard Biesheuvel Date: Tue, 7 Jul 2020 11:40:06 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH/RFC v7] ARM: boot: Obtain start of physical memory from DTB To: Geert Uytterhoeven X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200707_044019_098372_65BCCAB8 X-CRM114-Status: GOOD ( 37.79 ) 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 On Tue, 7 Jul 2020 at 11:35, Ard Biesheuvel wrote: > > On Tue, 7 Jul 2020 at 10:58, Geert Uytterhoeven wrote: > > > > 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? > > > > Yes you are right. > > > 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. > > Yes, but in the general case, this is not true. Platforms that manage > to boot using the current arrangement will do so by putting the > decompressor above the first 128 MB aligned boundary covered by DRAM > (and lose access to any memory below it via the linear mapping, but > this memory could still be used via a no-map reserved-memory node > AFAIK.) > > > 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? > > > > Maybe we both do :-) > > AIUI, the reason we cannot trust dram_start is because of the > crashkernel case, i.e., the kernel may have deliberately been put high > up in memory, and the expectation is that the load address is derived > by rounding down the load address of the decompressor. > > Hence my suggestion to round *up* and compare with dram_end: if > round_up(load_address, 128M) >= dram_end holds, it is guaranteed that > no address exists in memory from which we could round down and arrive > at a valid DRAM address. This would mean that your change will only > affect platforms that were unable to boot to begin with, and not > affect any other weird configurations including crashkernels etc Uhm maybe not ... Time to get that coffee... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel