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 Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3B8B2C05027 for ; Fri, 10 Feb 2023 07:26:26 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 0AF67858F9; Fri, 10 Feb 2023 08:26:24 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=andestech.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 93567858FB; Fri, 10 Feb 2023 08:26:22 +0100 (CET) Received: from Atcsqr.andestech.com (60-248-80-70.hinet-ip.hinet.net [60.248.80.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id C47E4858F8 for ; Fri, 10 Feb 2023 08:26:18 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=andestech.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ycliang@andestech.com Received: from mail.andestech.com (ATCPCS16.andestech.com [10.0.1.222]) by Atcsqr.andestech.com with ESMTP id 31A7Pqp8049521; Fri, 10 Feb 2023 15:25:52 +0800 (+08) (envelope-from ycliang@andestech.com) Received: from ubuntu01 (10.0.12.75) by ATCPCS16.andestech.com (10.0.1.222) with Microsoft SMTP Server id 14.3.498.0; Fri, 10 Feb 2023 15:25:48 +0800 Date: Fri, 10 Feb 2023 07:25:38 +0000 From: Leo Liang To: David Abdurachmanov CC: Xiang W , , , , , , Subject: Re: [PATCH v2] riscv: cancel the limitation that NR_CPUS is less than or equal to 32 Message-ID: References: <20211221233253.123268-1-wxjstz@126.com> <20211229092310.GA1314619@atcsi01> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.0.5 (2021-01-21) X-Originating-IP: [10.0.12.75] X-DNSRBL: X-MAIL: Atcsqr.andestech.com 31A7Pqp8049521 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean Hi Xiang, On Fri, Feb 03, 2023 at 03:24:37PM +0100, David Abdurachmanov wrote: > On Mon, Jan 3, 2022 at 1:13 PM Leo Liang wrote: > > > > On Thu, Dec 30, 2021 at 01:55:15AM +0800, Xiang W wrote: > > > 在 2021-12-29星期三的 17:23 +0800，Leo Liang写道： > > > > Hi Xiang, > > > > On Wed, Dec 22, 2021 at 07:32:53AM +0800, Xiang W wrote: > > > > > Various specifications of riscv allow the number of hart to be > > > > > greater than 32. The limit of 32 is determined by > > > > > gd->arch.available_harts. We can eliminate this limitation through > > > > > bitmaps. Currently, the number of hart is limited to 4095, and 4095 > > > > > is the limit of the RISC-V Advanced Core Local Interruptor > > > > > Specification. > > > > > > > > > > Test on sifive unmatched. > > > > > > > > > > Signed-off-by: Xiang W > > > > > --- > > > > > Changes since v1: > > > > > > > > > > * When NR_CPUS is very large, the value of GD_AVAILABLE_HARTS will > > > > > overflow the immediate range of ld/lw. This patch fixes this > > > > > problem > > > > > > > > > > arch/riscv/Kconfig | 4 ++-- > > > > > arch/riscv/cpu/start.S | 21 ++++++++++++++++----- > > > > > arch/riscv/include/asm/global_data.h | 4 +++- > > > > > arch/riscv/lib/smp.c | 2 +- > > > > > 4 files changed, 22 insertions(+), 9 deletions(-) > > > > > > > I noticed that this has never landed in U-Boot. Was this forgotten or > dropped for some reason (couldn't find anything)? > > The current limit on the Linux kernel side is 512. The default on > 64-bit (riscv64) is 64. > > david The patch seems to cause some CI error (timeout on QEMU). (https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/15076) Could you take a look at it if you have time? Best regards, Leo