From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8C54170 for ; Fri, 4 Jun 2021 09:55:33 +0000 (UTC) Received: from mail-wr1-f48.google.com ([209.85.221.48]) by mrelayeu.kundenserver.de (mreue009 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MWRZr-1lrSDg2ZSt-00XpPy for ; Fri, 04 Jun 2021 11:55:31 +0200 Received: by mail-wr1-f48.google.com with SMTP id m18so8689707wrv.2 for ; Fri, 04 Jun 2021 02:55:31 -0700 (PDT) X-Gm-Message-State: AOAM532H0ieQg4c6mhQLZncVEokv0Pq2CYoAVAE2JJSBRUMCNQ5uTa6v ZHBmeS6jkwiSfRrcTpJEmy9mCO5k/0lsfFd0O1U= X-Google-Smtp-Source: ABdhPJxshE3+Uw6+fWuekuuwJhK8oE6TcJIBm0QrwrkRRuWDjLhV71VM+ZrxsXwvq+Gqd5ead+heu/mutRyeZaqbM2U= X-Received: by 2002:a5d:5084:: with SMTP id a4mr3045824wrt.286.1622800531222; Fri, 04 Jun 2021 02:55:31 -0700 (PDT) X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: In-Reply-To: From: Arnd Bergmann Date: Fri, 4 Jun 2021 11:53:48 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC 0/3] riscv: Add DMA_COHERENT support To: Palmer Dabbelt Cc: Anup Patel , Guo Ren , Anup Patel , Drew Fustini , Christoph Hellwig , wefu@redhat.com, lazyparser@gmail.com, linux-riscv , Linux Kernel Mailing List , linux-arch , linux-sunxi@lists.linux.dev, Guo Ren , Paul Walmsley Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:y6e4Et7PTR9OARuPX8FYQmBHfUmt+FqZDH862x+mAYqgP1fJ96k YrTa9Wgf923xpC6KWCjyJL5/D5g2q2Na3/Q+2Txgr0QadnwrqmIUHDWp4ohjkK5j5jzUNbE 7bDqlIQ+ggfOR1hDUAAKLl17Xfg9ip+/ZkNDNhV4pzNxhnBA4+J+F8w30bOIME+vdL9Op2W oYRiXcDmTTxotmDpiGofg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:7OtS1lk+6A0=:fOJCsy+6c0L4ijcTSqNwfI rVpGy5g1E3dMwdxywqbJSrcVK6LeOJkd8d7AFtNT09pPQaBGUZZJh206C+NLdy/bZN3JfAUa1 sByoSfVkbu19Nb9PbNiAg/dmIvzZs3gW6cEe6zciNGdZCvQc+G7rndA2nZvFGgD2qQ/h7UN9J 2HOd79Htt3sgqFVjDk0WxWoGsjfbIpNhLyQTSk9XrPatfiGMB83BCK0pSpA4r4spMhk5/t5cX 9NTu2s83bIPE+pCoFsA8eB/LhcDeLS71HvWqMckhIUcjJfFV5VEtDlIp0k9/BbHpZMWp4U41U 9HnlIU/4ldwt+RezCWFkJ0vs9NCoaXURuIfjxAS8qKVK1IvIW5yxHuXrDLQVVEZEvK8cv9CYj PO1hgiC9B3knxfG0LcdFuao7q2NHUutnjsOq2UjVdu3oMYTQnE/BUperPGDPklOo2GzsO/rOB dLoda2akQO7RujZYnobE/XUadzyOSov5ETCF1pCF1zZJ1jFyBiVbvB9GfwWpTuargoJGpJ7TO eLOytbQZbIAz5m/WYctN4E= On Thu, Jun 3, 2021 at 5:39 PM Palmer Dabbelt wrote: > On Wed, 02 Jun 2021 23:00:29 PDT (-0700), Anup Patel wrote: > >> This implementation, which adds some Kconfig entries that control page table > >> bits, definately isn't suitable for upstream. Allowing users to set arbitrary > >> page table bits will eventually conflict with the standard, and is just going to > >> be a mess. It'll also lead to kernels that are only compatible with specific > >> designs, which we're trying very hard to avoid. At a bare minimum we'll need > >> some way to detect systems with these page table bits before setting them, > >> and some description of what the bits actually do so we can reason about > >> them. > > > > Yes, vendor specific Kconfig options are strict NO NO. We can't give-up the > > goal of unified kernel image for all platforms. > > I think this is just a phrasing issue, but just to be sure: > > IMO it's not that they're vendor-specific Kconfig options, it's that > turning them on will conflict with standard systems (and other vendors). > We've already got the ability to select sets of Kconfig settings that > will only boot on one vendor's system, which is fine, as long as there > remains a set of Kconfig settings that will boot on all systems. > > An example here would be the errata: every system has errata of some > sort, so if we start flipping off various vendor's errata Kconfigs > you'll end up with kernels that only function properly on some systems. > That's fine with me, as long as it's possible to turn on all vendor's > errata Kconfigs at the same time and the resulting kernel functions > correctly on all systems. Yes, this is generally the goal, and it would be great to have that working in a way where a 'defconfig' build just turns on all the options that are needed to use any SoC specific features and drivers while still working on all hardware. There are however limits you may run into at some point, and other architectures usually only manage to span some 10 to 15 years of hardware implementations with a single kernel before it get really hard. To give some common examples that make it break down: - 32-bit vs 64-bit already violates that rule on risc-v (as it does on most other architectures) - architectures that support both big-endian and little-endian kernels tend to have platforms that require one or the other (e.g. mips, though not arm). Not an issue for you. - page table formats are the main cause of incompatibility: arm32 and x86-32 require three-level tables for certain features, but those are incompatible with older cores, arm64 supports three different page sizes, but none of them works on all cores (4KB almost works everywhere). - SMP-enabled ARMv7 kernels can be configured to run on either ARMv6 or ARMv8, but not both, in this case because of incompatible barrier instructions. - 32-bit Arm has a couple more remaining features that require building a machine specific kernel if enabled because they hardcode physical addresses: early printk (debug_ll, not the normal earlycon), NOMMU, and XIP. Arnd 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=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 CF441C47083 for ; Fri, 4 Jun 2021 09:55:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B594761411 for ; Fri, 4 Jun 2021 09:55:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229718AbhFDJ5T (ORCPT ); Fri, 4 Jun 2021 05:57:19 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:54809 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229612AbhFDJ5S (ORCPT ); Fri, 4 Jun 2021 05:57:18 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]) by mrelayeu.kundenserver.de (mreue107 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MStT6-1lxFW92Wvm-00UIut; Fri, 04 Jun 2021 11:55:31 +0200 Received: by mail-wr1-f46.google.com with SMTP id n4so8693614wrw.3; Fri, 04 Jun 2021 02:55:31 -0700 (PDT) X-Gm-Message-State: AOAM530G01n//Al712oHcoMIMzVLTZxFDqgmFw0SjcZgKvc0CmI1nopl uB5yQNLOdSO8sS8frGfs7BOsGpO7ZuloHmNwS5s= X-Google-Smtp-Source: ABdhPJxshE3+Uw6+fWuekuuwJhK8oE6TcJIBm0QrwrkRRuWDjLhV71VM+ZrxsXwvq+Gqd5ead+heu/mutRyeZaqbM2U= X-Received: by 2002:a5d:5084:: with SMTP id a4mr3045824wrt.286.1622800531222; Fri, 04 Jun 2021 02:55:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Arnd Bergmann Date: Fri, 4 Jun 2021 11:53:48 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC 0/3] riscv: Add DMA_COHERENT support To: Palmer Dabbelt Cc: Anup Patel , Guo Ren , Anup Patel , Drew Fustini , Christoph Hellwig , wefu@redhat.com, lazyparser@gmail.com, linux-riscv , Linux Kernel Mailing List , linux-arch , linux-sunxi@lists.linux.dev, Guo Ren , Paul Walmsley Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:ujRpXPvNy6Jxro+egqdLKAw5vJR180w7QwlpXdBCHfIrGqxinQz nQR6+KvWR5sJYROEuH+FIIRH7X5P5IFQfZluaWm0Xb5kyNaV0B7BaOLps8CU3h3XVMBAM7P sKR34naXwcGgeXlVXbcuOEoJERzv7eIIjYr6lcDFIOI20I1iBL0sUaGb9LCmNr3+vYkq44f BZ6xm+eanWz4z78eCRBMQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:jAKJ4I7p/2A=:QHvYiqwgjPgKFMmyiSeKYu S5rKt7mk11ggGKf8g/VCPt+F29wFssyG7Zhp5YYohJ9JI/2fJTZQvxvzw+zZ/wgqSQF4Z52tY U9yVnOv1UtRm0q0rxlVM9MOxjhgdAcaue1a1fBafAnvE689xK3+uhaFUzQ7xZIgK5KxtYc+aI 2iSmArr6eOAYc2TNeB1usZ+tfqiLsaBEsC2EIhePp3JyzHTjE7fDQzNasEKXjc4dSasMs6ldR OISdpDtE3rsZZfMH+XAB6G7FnwehxwB/e+ZIFULx6bGZRxD+DQxdTzWRKYXvkGOQJon6ypsZw t84J0z8nlYGp6LQjIKZuxoxxA35HN04Lhj7/h1K1vCL7HpbRFC546GBkTjohKw7b0JS4SgKRd feDXme/jATzM2I+OcM5vpnizamXT23ETgrBG5L+DDGZ3pjlWwPdYEm4FzhBDda23/l2stzWpG 4d9+KVUP2VXyhjO8yItd5SJ67bXmCPRr0EtVgi6y2qzTHUd9R5YvnlgTO4+dM2IvoaOhBmVUK pBmTQ/bOhEapuxjWmOINIdLUSH58z+cckD/Ouj653zmPU0SB24TxIL0OkE5nYFD68kZPuJBuK iIChdF/JDVn2DCBObSi1NyQYbHAhNNT7+F83RYVjmwOcHYs0diCe8WSd0QbigeNUbjhzo/yJP wkGM= Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 3, 2021 at 5:39 PM Palmer Dabbelt wrote: > On Wed, 02 Jun 2021 23:00:29 PDT (-0700), Anup Patel wrote: > >> This implementation, which adds some Kconfig entries that control page table > >> bits, definately isn't suitable for upstream. Allowing users to set arbitrary > >> page table bits will eventually conflict with the standard, and is just going to > >> be a mess. It'll also lead to kernels that are only compatible with specific > >> designs, which we're trying very hard to avoid. At a bare minimum we'll need > >> some way to detect systems with these page table bits before setting them, > >> and some description of what the bits actually do so we can reason about > >> them. > > > > Yes, vendor specific Kconfig options are strict NO NO. We can't give-up the > > goal of unified kernel image for all platforms. > > I think this is just a phrasing issue, but just to be sure: > > IMO it's not that they're vendor-specific Kconfig options, it's that > turning them on will conflict with standard systems (and other vendors). > We've already got the ability to select sets of Kconfig settings that > will only boot on one vendor's system, which is fine, as long as there > remains a set of Kconfig settings that will boot on all systems. > > An example here would be the errata: every system has errata of some > sort, so if we start flipping off various vendor's errata Kconfigs > you'll end up with kernels that only function properly on some systems. > That's fine with me, as long as it's possible to turn on all vendor's > errata Kconfigs at the same time and the resulting kernel functions > correctly on all systems. Yes, this is generally the goal, and it would be great to have that working in a way where a 'defconfig' build just turns on all the options that are needed to use any SoC specific features and drivers while still working on all hardware. There are however limits you may run into at some point, and other architectures usually only manage to span some 10 to 15 years of hardware implementations with a single kernel before it get really hard. To give some common examples that make it break down: - 32-bit vs 64-bit already violates that rule on risc-v (as it does on most other architectures) - architectures that support both big-endian and little-endian kernels tend to have platforms that require one or the other (e.g. mips, though not arm). Not an issue for you. - page table formats are the main cause of incompatibility: arm32 and x86-32 require three-level tables for certain features, but those are incompatible with older cores, arm64 supports three different page sizes, but none of them works on all cores (4KB almost works everywhere). - SMP-enabled ARMv7 kernels can be configured to run on either ARMv6 or ARMv8, but not both, in this case because of incompatible barrier instructions. - 32-bit Arm has a couple more remaining features that require building a machine specific kernel if enabled because they hardcode physical addresses: early printk (debug_ll, not the normal earlycon), NOMMU, and XIP. Arnd 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=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, 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 9BCC0C07E94 for ; Fri, 4 Jun 2021 09:55:55 +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 620D661411 for ; Fri, 4 Jun 2021 09:55:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 620D661411 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+linux-riscv=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.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc: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=IpHjRLNEPc7V46naw9j9Hq2CXuoo0zJtTo/3BgEQdYo=; b=ImnUf9Tnn0Rsjz eI8HBgRbzde3oNI+Ed2LZOS9tIBOvFldx/kqhwubkaHN+yoWf3U+roHRrvpAEdTytMHIWy8FVGR4y uz3s/ZHwOKj5+ouk6BN9v2hdeUjEgSGUNx8p9kGpuzEZ8h/RDLRi1Kbfg6WZO6IuLIhlKNDRdei/y hKPfrkxoVBfhPWGCTpJp7NXmh1+HFDp2sn7VMp8cZzh1pnSzwR1XBQG2aAMdf5qt9gI+9ZuhiXA9p Pj+N/nkj89lvCgBtUc4tJW/lhUixq9+9FAlfRjqCySmU2xDcEgTkKmjtgDo6tXdzUuTCg7kjaYOzE CVxi3ctWzf3XekO0Mneg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lp6YF-00ClXp-PT; Fri, 04 Jun 2021 09:55:39 +0000 Received: from mout.kundenserver.de ([212.227.126.130]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lp6YC-00ClW6-0A for linux-riscv@lists.infradead.org; Fri, 04 Jun 2021 09:55:37 +0000 Received: from mail-wr1-f45.google.com ([209.85.221.45]) by mrelayeu.kundenserver.de (mreue011 [213.165.67.97]) with ESMTPSA (Nemesis) id 1Mgebs-1lAFQ725yG-00h7Uk for ; Fri, 04 Jun 2021 11:55:31 +0200 Received: by mail-wr1-f45.google.com with SMTP id a20so8730579wrc.0 for ; Fri, 04 Jun 2021 02:55:31 -0700 (PDT) X-Gm-Message-State: AOAM530Sw4LVTTc4FSgAuxpcOWtorjyxVtrhKFWfVN2g1Hzja4Y+SLAR jztpiK++eyFroMiSrhdXHubptPgt8FfWbPL+co4= X-Google-Smtp-Source: ABdhPJxshE3+Uw6+fWuekuuwJhK8oE6TcJIBm0QrwrkRRuWDjLhV71VM+ZrxsXwvq+Gqd5ead+heu/mutRyeZaqbM2U= X-Received: by 2002:a5d:5084:: with SMTP id a4mr3045824wrt.286.1622800531222; Fri, 04 Jun 2021 02:55:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Arnd Bergmann Date: Fri, 4 Jun 2021 11:53:48 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC 0/3] riscv: Add DMA_COHERENT support To: Palmer Dabbelt Cc: Anup Patel , Guo Ren , Anup Patel , Drew Fustini , Christoph Hellwig , wefu@redhat.com, lazyparser@gmail.com, linux-riscv , Linux Kernel Mailing List , linux-arch , linux-sunxi@lists.linux.dev, Guo Ren , Paul Walmsley X-Provags-ID: V03:K1:5n5g3G5xtua3c+FuFfsnsfbJUZZvWQtNjmCNhHk2/xqmmtjYMkT P6ufsQlFJEM1W0McGYA/xTm8KQKfBmuFIJZWDaj2px+3S94VU1b/wbnZSl8IZ0p5blmokSu sP0bugf4uWRwb0MNMQq+3QfoBjH8e0IleVHkr4oZfTQbdwE8IGcyf97X2WFUa1QqpvKo5fT ypOvNp1CByB/m2QiWKkZQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:FhSwdiYNnds=:Ga4qt0E5Sk67io3T0oJfVG HaFOOusm5giBmmFiVWjgJ/H8Z/bnTq6QiCgAoCKhPJcVbFSUxtkyVhK569m8Z6qSMs1Ut36+9 0KPXcVKe3GuV20NA+hE1fg1hijZ1v5KCFU9Fbm1FTMxasyIs2O7MgdIvb/Yqp79fsQvGEDTOC ncpvk5dOg8y7tqdmJIrQRAvDKeloYusmrv1BDhU3/adCDx9tNFOJZpVfBsGb/IWaDbD7qRHZC C0NzwbbS9I3rSf3flL1BAPXVrQSWwP8M/pIQGd9L0UWzB1ZLWiQvjlkX6xp5g4RB0CIEpElyx WKTwo5OsksRE8Y4qHcnE6iD1pRppLPbfBiCyWAc83LR4ThdlpAzn+9DGEq/714QPbO2sNR229 HtgaclQnk6MoxOP4Hf8JYgg2zceRF9JY5dXXOdefGyjq1WMh3yprhmPTMzt7HdMCdvDD6bSO7 Yr8JkqsKF33vhYoINNAGUCh/GZQSu89KLH8Y/HiSuwn4BJneagxJtyJMJ7KPAn++jYDLrpXCQ ewsj4E2ZNmOPb2skOHUaYc= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210604_025536_364580_6EE7410E X-CRM114-Status: GOOD ( 32.57 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Thu, Jun 3, 2021 at 5:39 PM Palmer Dabbelt wrote: > On Wed, 02 Jun 2021 23:00:29 PDT (-0700), Anup Patel wrote: > >> This implementation, which adds some Kconfig entries that control page table > >> bits, definately isn't suitable for upstream. Allowing users to set arbitrary > >> page table bits will eventually conflict with the standard, and is just going to > >> be a mess. It'll also lead to kernels that are only compatible with specific > >> designs, which we're trying very hard to avoid. At a bare minimum we'll need > >> some way to detect systems with these page table bits before setting them, > >> and some description of what the bits actually do so we can reason about > >> them. > > > > Yes, vendor specific Kconfig options are strict NO NO. We can't give-up the > > goal of unified kernel image for all platforms. > > I think this is just a phrasing issue, but just to be sure: > > IMO it's not that they're vendor-specific Kconfig options, it's that > turning them on will conflict with standard systems (and other vendors). > We've already got the ability to select sets of Kconfig settings that > will only boot on one vendor's system, which is fine, as long as there > remains a set of Kconfig settings that will boot on all systems. > > An example here would be the errata: every system has errata of some > sort, so if we start flipping off various vendor's errata Kconfigs > you'll end up with kernels that only function properly on some systems. > That's fine with me, as long as it's possible to turn on all vendor's > errata Kconfigs at the same time and the resulting kernel functions > correctly on all systems. Yes, this is generally the goal, and it would be great to have that working in a way where a 'defconfig' build just turns on all the options that are needed to use any SoC specific features and drivers while still working on all hardware. There are however limits you may run into at some point, and other architectures usually only manage to span some 10 to 15 years of hardware implementations with a single kernel before it get really hard. To give some common examples that make it break down: - 32-bit vs 64-bit already violates that rule on risc-v (as it does on most other architectures) - architectures that support both big-endian and little-endian kernels tend to have platforms that require one or the other (e.g. mips, though not arm). Not an issue for you. - page table formats are the main cause of incompatibility: arm32 and x86-32 require three-level tables for certain features, but those are incompatible with older cores, arm64 supports three different page sizes, but none of them works on all cores (4KB almost works everywhere). - SMP-enabled ARMv7 kernels can be configured to run on either ARMv6 or ARMv8, but not both, in this case because of incompatible barrier instructions. - 32-bit Arm has a couple more remaining features that require building a machine specific kernel if enabled because they hardcode physical addresses: early printk (debug_ll, not the normal earlycon), NOMMU, and XIP. Arnd _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv