Received: by 2002:a89:d88:0:b0:1fa:5c73:8e2d with SMTP id eb8csp2012777lqb; Mon, 27 May 2024 05:17:39 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCUDm2GyG1NOhGencjXqLRq32vhvIpAQiRgeFCmJ+gqXaz7MoGRMsKlUaftROPnsQkxruzIozMSZSf0HWSgGghueuIY+WGKf5LnGcexL/A== X-Google-Smtp-Source: AGHT+IHZh8c3ZXVUoqxovXGOkPpkOPr8F3KppJjgetwWFmGZSjht1dZ//s7sxFsxeyew+wI9MlMO X-Received: by 2002:a05:6a20:728a:b0:1af:58d3:2288 with SMTP id adf61e73a8af0-1b205c9b2f4mr18242764637.15.1716812259079; Mon, 27 May 2024 05:17:39 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1716812259; cv=pass; d=google.com; s=arc-20160816; b=c3CfqCIWwv3WlWhfen2f8NrhX9XCwP/wJMKK56RMUXMQ6DjAIs6orBUYH2DcVhK4Wn zU9XelzH2GIbmCvpUpNIYWKxfiBUkkiIHnqoyDMFYm6r1v+B0sn5d74g+W33Iu8net6U C8Zy/dkC17MBd00LLfoqn3jV86V6Kz8Ie78EO3FnP5wiIlyeU1smr1Sc5TbeQGeaETKv hM04qmkAJKtUiafsmK8zSCNNbPcX5cL5krFPM3nPzry9FdvF5aWU0WuKRpd1grggNIvT rb3h9vOl7kglxEQp1BM9QIbwWT+tI8jhRPKJcwXWTsiSPZRTf6vhEA2timIGDKxV0fRm mF+g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=N0S3qpJXwEiXLRw4Q1bqR4i47psDdS1LRIMYCP1xw6k=; fh=lgqf/2hPwG2M7gRtKgFgMgxVxmGbeZObC5Z3x8Y7aow=; b=RnMDsnznadpsZ8GKiB2yCRHT6iprylwzhZ5ujQV7BQcwh/LNDEioFiqDDlYWJBv0V+ CW8UziCVdQa8HS6SCQnjY3oQ5k6GXaUfSSITIh28pCFLThf1dkfLssAGorOH+B0dSABx Mhg5bFbK6Kf3fw7pfpmFUyoZASl9NZRFu+wOfMEv/hZNKX5YqbUQIFgOJNzc1r0FEx6d nUb8KGP1OZIpzzKdCcCJ9azLLX/7Bg99fc4krOn1voVjl8/6GVc5Yj0zks36RRB/Y9ah rljRGipI+PB6kseyMOyd/B6KWTDTvNqpwOHicjDdLO+cDBrznqS/Gvd4gA/0QaRz3T+l 4XTA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=ghiti.fr); spf=pass (google.com: domain of linux-kernel+bounces-190556-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-190556-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id 41be03b00d2f7-68222db0f63si6500521a12.238.2024.05.27.05.17.38 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 May 2024 05:17:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-190556-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=ghiti.fr); spf=pass (google.com: domain of linux-kernel+bounces-190556-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-190556-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id B610C2873B4 for ; Mon, 27 May 2024 12:17:38 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D0D3515E5BB; Mon, 27 May 2024 12:17:02 +0000 (UTC) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (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 3D12913C3CA for ; Mon, 27 May 2024 12:16:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.183.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716812222; cv=none; b=pUQ4K5SPy6fHZ8x/ZeWfGjnlHfWwvRGbve2DfEX1z8kkapcETj0CDvQf8iLZEhYCn31p4MfRxWC845TYukdX2EYhv0SPhMWuy2AbbEgjA9PUOj2SygWoeqGWsDu5qRZBMnVEiwIuMBHSQSkkZ9dYlu+e8siXZAkN/PCw4Oci2c4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716812222; c=relaxed/simple; bh=4rmwT8fMBWaUg4ppZqnb51hiutGTSWM0Qo7P2tV1PV4=; h=Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type; b=mZIYXvyjxqnvThF2AjGRBKGgxP29igGkJWYzhKpsocgkAK79oSs5D0TUQbxZhSBKyCyD6N1J0zM8qN+rFcqBL6aBwxndE8HhHLVucQPRzoE4RBLuAWi6tNzIponBu0f5O5MoJocSbVoQHDhW1Ui9ngVEWvR6QKy6+55mao2Cv5g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ghiti.fr; spf=pass smtp.mailfrom=ghiti.fr; arc=none smtp.client-ip=217.70.183.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ghiti.fr Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ghiti.fr Received: by mail.gandi.net (Postfix) with ESMTPSA id 3B5AA60011; Mon, 27 May 2024 12:16:57 +0000 (UTC) Message-ID: Date: Mon, 27 May 2024 14:16:56 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/7] riscv: cleanup XIP_FIXUP macro Content-Language: en-US To: Nam Cao , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org References: <19e63324d7a099f561c4a2e55f7df051bd5b8a6f.1715286093.git.namcao@linutronix.de> From: Alexandre Ghiti In-Reply-To: <19e63324d7a099f561c4a2e55f7df051bd5b8a6f.1715286093.git.namcao@linutronix.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-GND-Sasl: alex@ghiti.fr Hi Nam, On 10/05/2024 08:28, Nam Cao wrote: > The XIP_FIXUP macro is used to fix addresses early during boot before MMU: > generated code "thinks" the data section is in ROM while it is actually in > RAM. So this macro correct the addresses in the data section. > > This macro determines if the address needs to be fixed by checking if it is > within the range startting of ROM address up to the size of 2 * XIP_OFFSET s/startting/starting And the sentence lacks the final dot. > > This means addresses within the .text section would incorrectly get fixed. Yes, but XIP_FIXUP() should only be applied to data symbols so I believe this ^ is not relevant. > Also if the kernel size if bigger than (2 * XIP_OFFSET), some addresses > would not be fixed up. s/the kernel size if/the kernel size is > > XIP kernel can still work if the above 2 cases do not happen. But this > macro is obviously incorrect. > > Rewrite this macro to only fix up addresses within the data section. > > Signed-off-by: Nam Cao > --- > arch/riscv/include/asm/pgtable.h | 11 +++++++---- > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > index 58fd7b70b903..fbf342f4afee 100644 > --- a/arch/riscv/include/asm/pgtable.h > +++ b/arch/riscv/include/asm/pgtable.h > @@ -139,11 +139,14 @@ > > #ifdef CONFIG_XIP_KERNEL > #define XIP_FIXUP(addr) ({ \ > + extern char _sdata[], _start[], _end[]; \ > + uintptr_t __rom_start_data = CONFIG_XIP_PHYS_ADDR \ > + + (uintptr_t)&_sdata - (uintptr_t)&_start; \ > + uintptr_t __rom_end_data = CONFIG_XIP_PHYS_ADDR \ > + + (uintptr_t)&_end - (uintptr_t)&_start; \ > uintptr_t __a = (uintptr_t)(addr); \ > - (__a >= CONFIG_XIP_PHYS_ADDR && \ > - __a < CONFIG_XIP_PHYS_ADDR + XIP_OFFSET * 2) ? \ > - __a - CONFIG_XIP_PHYS_ADDR + CONFIG_PHYS_RAM_BASE - XIP_OFFSET :\ > - __a; \ > + (__a >= __rom_start_data && __a < __rom_end_data) ? \ > + __a - __rom_start_data + CONFIG_PHYS_RAM_BASE : __a; \ > }) > #else > #define XIP_FIXUP(addr) (addr) Reviewed-by: Alexandre Ghiti Thanks, Alex