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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 D2CFCC38A2A for ; Fri, 8 May 2020 15:56:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B3E3C20CC7 for ; Fri, 8 May 2020 15:56:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726815AbgEHP4f (ORCPT ); Fri, 8 May 2020 11:56:35 -0400 Received: from mail-oi1-f193.google.com ([209.85.167.193]:35339 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726770AbgEHP4f (ORCPT ); Fri, 8 May 2020 11:56:35 -0400 Received: by mail-oi1-f193.google.com with SMTP id o7so8832879oif.2 for ; Fri, 08 May 2020 08:56:34 -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=+GKUewSWahMzbTGK4Irc6ZImh8HZvmgtHXE2/q/YsbY=; b=BrIEgznMJBVItIDyGFYjWKmYsoVDlfsC3bXSUiiwQf+npH/SL5l9S0nYnpbu2zCwdI RPL6BoFWche9L96AusBOG7BCue5gXE42Q8r1tg1yXf/LkEL/XspbuYM+519Umm2jJk4u Z/Vs2fCoNTnKDvXeCMQe8CUtemcS6B46EaAJx6dCGPMTGwQGfDoTDZLLe8s887jUz1f5 jxE4lH9H3Ni9+y6aap6sfYDJx3wN1E35yK8XodB2ny/zlSTwzXn54Ij41/pOdMM3Ii/R L8Lf8642L6QgmztwcNor6sY7+WUxX9vKiK/fgM7K9OhsjuNguipz+dMyJ+88r6/PmEUw jEFA== X-Gm-Message-State: AGi0PuYXOOC0CKXFp2ggT/1g4nNHG/t0behYEIHYUDnRjsBtqg4acPRs AsUrt/1WveJOkHKf22NF70j2qr/Wyyx1WMUfoZY= X-Google-Smtp-Source: APiQypKL9fUgGlobVYbD8ZVeb4rJeP/CAXgTk+gBY4MoyW9NLz3SmymX2vn2ZDSavA3bXeL5QEMTJIiKqTMwdSwmAOw= X-Received: by 2002:aca:d50f:: with SMTP id m15mr10967981oig.54.1588953394204; Fri, 08 May 2020 08:56:34 -0700 (PDT) MIME-Version: 1.0 References: <20200507080528.547-1-geert+renesas@glider.be> In-Reply-To: From: Geert Uytterhoeven Date: Fri, 8 May 2020 17:56:22 +0200 Message-ID: Subject: Re: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM To: Nicolas Pitre Cc: Chris Brandt , Magnus Damm , Arnd Bergmann , Russell King , Linux-Renesas , Linux ARM 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 Hi Nicolas, On Fri, May 8, 2020 at 4:41 PM Nicolas Pitre wrote: > On Fri, 8 May 2020, Chris Brandt wrote: > > The big argument was always that "XIP cannot be multi-platform by > > definition because RAM/ROM always resides at different addresses in different > > devices". And as you know, the physical address for RAM and ROM have to > > be hard coded in the kernel binary. > > Exact. So what is the problem? Ah, you've fallen for the "multi-platform" fallacy! I have no desire to enable support for multiple platforms in a single kernel that supports XIP on all platforms. I merely want it to be possible to build a XIP kernel for one platform. As ARM v7m systems must be part of the ARCH_MULTI_V7 gang, they cannot enable the XIP_KERNEL config symbol. [PATCH] [RFC] arm: Replace "multiple platforms" by "common platform" http://lore.kernel.org/r/20180621155906.12821-1-geert+renesas@glider.be > > At an ELC a while back, I talked to Arnd and his suggestion was to put > > the base addresses for RAM and ROM at a fixed location in the kernel > > binary. Then for each SoC, you manually modify those values in the each > > binary to match your board. This means there is 'technically' a single build > > that will support all boards. Interesting. I didn't know that suggestion. Sounds doable (but see below). > The very reason for using XIP in the first place is to maximize resource > savings on constrained platforms. Any notion of a multi-platform kernel > is completely contrary to this goal. This is even more true for no-MMU > platforms where you can't abstract physical address differences behind a > page table. > > Multi-platform kernel supporting all boards make sense for generic > distros and/or build coverage tests. But a multi-platform XIP kernel is > a nonsense. Trying to make XIP multi-platform might be a nice > intellectual challenge but that has zero value for actual deployment and > usage. Agreed. > Given that there isn't a lot of such platforms anyway, it should be > possible to carry a few kconfig entries outside of the multi-platform > menu for XIP targets and live with possible kconfig duplicates. That > shouldn't be such a maintenance burden. Still, it's duplication, which could be avoided using a single "know what you're doing" Kconfig option. And it will grow, as XIP could be used on lots of platforms. I believe this is exactly what Chris' last attempt did? 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 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=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,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 9793FC38A2A for ; Fri, 8 May 2020 15:56:39 +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 6F88E20CC7 for ; Fri, 8 May 2020 15:56:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="LvBZBLh6" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6F88E20CC7 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+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: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=ESchtCnUIGJ2MWO8qytFGn3IjvzHSRlOA7ZXMXzlVP0=; b=LvBZBLh6CHQtZm yVz6P6uepyemrfJdqrSkn3eqH2Yw9mnDIXnpx/rMOCEW9lA4wfGmsoR7lYgZK59z8b0vMqbM0BNrD eq3oTT/vyrjwehE6bOJf9ikCWXMdZ1rjGaD/A9hqh5z1u3WmqNBNkCRbLqE8u1ZZUcX64LZXjIO9q Mbhqrq9fapPWsrBeM7Z/pwXiXUvZu0898J3FjOiZCz7n3yOuVaVQXSbBHFWX8GS2zsKkbN7D5bPD8 ZV8vnf+TMvRXWxOVk5vG8URCDNHZpquwPpkWdogHFXfmGW0IaKsCFY8YCPY++L1DQLVHQ4w6Gji0q L9OC6GpTrmi2jGDosKwQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jX5Md-0000fP-2m; Fri, 08 May 2020 15:56:39 +0000 Received: from mail-oi1-f193.google.com ([209.85.167.193]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jX5MZ-0000ef-Na for linux-arm-kernel@lists.infradead.org; Fri, 08 May 2020 15:56:37 +0000 Received: by mail-oi1-f193.google.com with SMTP id j16so8792190oih.10 for ; Fri, 08 May 2020 08:56:34 -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=+GKUewSWahMzbTGK4Irc6ZImh8HZvmgtHXE2/q/YsbY=; b=p0Tc80O1Cuu6LWWvZQVo3FyaBO8ZI8u6iv5ZayKFuy29LaViX39ANokU0FvabpaQTM a6JKPFj4Pso6LfXPnKlhuQpHV86W3JsJpzOYl5pLJrQYmODY/r83V4rPkYrAYRlB2ii4 +2KdEhCz0YEwn5A7KUZp0pmWVUxSMgtYlrrtPtZWBsaTGUHrl/9/uKpMflssbqHJjQ4I isM/AbWsdxlkQdzzNOI/zGH/ZQo3A80vhMUdcnzwYfHqiaZHAZ3w3GOoDaR0WYJ/nlxx cIrqDFR6k6DUAsehUHW+smaJtQmkxFLLrGBevTFCFRp/y6wLU5jQpX2ul2bvYlOzRhzw vNkg== X-Gm-Message-State: AGi0Pua7JcP4AK+M3x3WRLbHfRLQeOFoVb9NSWMf+YbDIjBQgexAuaYX DSyTyqEV+1MtgnaHH5OOr6B/xLgdyzvo0Uk27EI= X-Google-Smtp-Source: APiQypKL9fUgGlobVYbD8ZVeb4rJeP/CAXgTk+gBY4MoyW9NLz3SmymX2vn2ZDSavA3bXeL5QEMTJIiKqTMwdSwmAOw= X-Received: by 2002:aca:d50f:: with SMTP id m15mr10967981oig.54.1588953394204; Fri, 08 May 2020 08:56:34 -0700 (PDT) MIME-Version: 1.0 References: <20200507080528.547-1-geert+renesas@glider.be> In-Reply-To: From: Geert Uytterhoeven Date: Fri, 8 May 2020 17:56:22 +0200 Message-ID: Subject: Re: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM To: Nicolas Pitre X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200508_085635_767296_9C6B415F X-CRM114-Status: GOOD ( 20.18 ) 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 , Magnus Damm , Russell King , Linux-Renesas , Chris Brandt , Linux ARM 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 Nicolas, On Fri, May 8, 2020 at 4:41 PM Nicolas Pitre wrote: > On Fri, 8 May 2020, Chris Brandt wrote: > > The big argument was always that "XIP cannot be multi-platform by > > definition because RAM/ROM always resides at different addresses in different > > devices". And as you know, the physical address for RAM and ROM have to > > be hard coded in the kernel binary. > > Exact. So what is the problem? Ah, you've fallen for the "multi-platform" fallacy! I have no desire to enable support for multiple platforms in a single kernel that supports XIP on all platforms. I merely want it to be possible to build a XIP kernel for one platform. As ARM v7m systems must be part of the ARCH_MULTI_V7 gang, they cannot enable the XIP_KERNEL config symbol. [PATCH] [RFC] arm: Replace "multiple platforms" by "common platform" http://lore.kernel.org/r/20180621155906.12821-1-geert+renesas@glider.be > > At an ELC a while back, I talked to Arnd and his suggestion was to put > > the base addresses for RAM and ROM at a fixed location in the kernel > > binary. Then for each SoC, you manually modify those values in the each > > binary to match your board. This means there is 'technically' a single build > > that will support all boards. Interesting. I didn't know that suggestion. Sounds doable (but see below). > The very reason for using XIP in the first place is to maximize resource > savings on constrained platforms. Any notion of a multi-platform kernel > is completely contrary to this goal. This is even more true for no-MMU > platforms where you can't abstract physical address differences behind a > page table. > > Multi-platform kernel supporting all boards make sense for generic > distros and/or build coverage tests. But a multi-platform XIP kernel is > a nonsense. Trying to make XIP multi-platform might be a nice > intellectual challenge but that has zero value for actual deployment and > usage. Agreed. > Given that there isn't a lot of such platforms anyway, it should be > possible to carry a few kconfig entries outside of the multi-platform > menu for XIP targets and live with possible kconfig duplicates. That > shouldn't be such a maintenance burden. Still, it's duplication, which could be avoided using a single "know what you're doing" Kconfig option. And it will grow, as XIP could be used on lots of platforms. I believe this is exactly what Chris' last attempt did? 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