From nobody Sun Dec 14 11:53:28 2025 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 1CE3913D29E for ; Fri, 7 Jun 2024 20:22:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717791737; cv=none; b=FV0UwOv9rfnvA9/Dz91EpuDVCmpnYghILkQujJf9OwANBQ4B0TW4b8jIjDMFb42f4T2iRUtTSl9lCdu7Sy3qq+sQxk23+i6Vd7Wz8rTvcyV5If+9cG0wXiJS6pkuoMQwDxd/XjiOuUWBSKWrxVdAjrQVEblaohcj1ZzoCPmqVqU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717791737; c=relaxed/simple; bh=NRwjMMW1NpcsWO7RJK+bpTO7Rv+OtExdexlMAAkxYns=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Uh0oVCigxfnWRQb0lpplr6w80RWVe5uwg6Lj2VllR+94Sh1p9FcwZUoRf21cTuqLZ0qDVdMMhK5Pw7MzMmWSUXfZq4dmOGH5mAqKo2h2kIle64GgVjHOw6mEok0VP7PS+uO20A1CHPdxm+gSV5Ml6xrGoaObNkeePp8xSa6Ugmg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=zVDZmWbz; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=gO8J18Er; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="zVDZmWbz"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="gO8J18Er" From: Nam Cao DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1717791734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9qZuhyf1lQhZt5s3eJFi8xrQOgugcSrfCBUJNf59gow=; b=zVDZmWbztBHi/M21/7J+Y5FeFxkTdBDatbLJyQAc/z8s1fHROXf0zBSzAL/ulQstFpGyrg zfRyUsZci059OwtCvS4pPWPeybEYXmpYcl9KeVkQu3D0dYr0+ETILmKDEpVxQoF8CRCx2B sgtVFRsKdkiMvSQy+OvKMhL1FQfSyJE4OtbAw0xLHV7tu+ob99ohN3mARhPZGooCxxsUo4 ojVMsEJt0VI0ymsM0cqCF8hlbGz5FeazRfVXsJj4cRo8eNrFYN/l3pWMIMby3HtBU6WTZ7 OJkRVLCe8REVuuhkiXTne8T9cvBMoyFqfw5HrwgNpo4eqoyRdtqGWelHmpJgkA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1717791734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9qZuhyf1lQhZt5s3eJFi8xrQOgugcSrfCBUJNf59gow=; b=gO8J18EreVY72dp9ASgoYtgplWRm+hThsi87epU0keVDaiDb0vsxg5HPVyY/g/jh5RcHeY CVYR7vY5j36RVlBQ== To: Alexandre Ghiti , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 1/8] riscv: cleanup XIP_FIXUP macro Date: Fri, 7 Jun 2024 22:22:06 +0200 Message-Id: <95f50a4ec8204ec4fcbf2a80c9addea0e0609e3b.1717789719.git.namcao@linutronix.de> In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 corrects the addresses in the data section. This macro determines if the address needs to be fixed by checking if it is within the range starting from ROM address up to the size of (2 * XIP_OFFSET). This means if the kernel size is bigger than (2 * XIP_OFFSET), some addresses would not be fixed up. XIP kernel can still work if the above scenario does 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 Reviewed-by: Alexandre Ghiti --- 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/pgta= ble.h index aad8b8ca51f1..1bc103aa9b74 100644 --- a/arch/riscv/include/asm/pgtable.h +++ b/arch/riscv/include/asm/pgtable.h @@ -142,11 +142,14 @@ =20 #ifdef CONFIG_XIP_KERNEL #define XIP_FIXUP(addr) ({ \ + extern char _sdata[], _start[], _end[]; \ + uintptr_t __rom_start_data =3D CONFIG_XIP_PHYS_ADDR \ + + (uintptr_t)&_sdata - (uintptr_t)&_start; \ + uintptr_t __rom_end_data =3D CONFIG_XIP_PHYS_ADDR \ + + (uintptr_t)&_end - (uintptr_t)&_start; \ uintptr_t __a =3D (uintptr_t)(addr); \ - (__a >=3D 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 >=3D __rom_start_data && __a < __rom_end_data) ? \ + __a - __rom_start_data + CONFIG_PHYS_RAM_BASE : __a; \ }) #else #define XIP_FIXUP(addr) (addr) --=20 2.39.2 From nobody Sun Dec 14 11:53:28 2025 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 1CD7833EE for ; Fri, 7 Jun 2024 20:22:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717791737; cv=none; b=lZcSV8dIgbpBgcZQhXKkkPR6YWkWWq7hLpQ2L0d2sE1bUQEKDDN/iW7W61B22NOgw/k5XJh+wsnSdPZuiR1S3wrKSCiS0lJhFry4H6aJiNUJOOg/qXFYFaNcjKbVFwTKPb2B1TZLW0V8EJfyeloF+1EQ33nYmhXODNY6fHgSnns= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717791737; c=relaxed/simple; bh=YxUzYoHE+R+dtYjDWQYkl313ZUeVoqUy01UITCRL2ek=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=APn0MfR3ATJub/uXzdGHUk6QpBZqCsIVKMYhDEjmwgp9JFmpHCLeb8IRoJmEGgYJXGcRW389oCQLZz0mWK8YqGTWqQChVBv24ymRC8V/7djyWXJEfbKtzcomj5pRtqP/JQWLozU9DU5PWsyboT5Uu4aIDZ5I+5HFS2xz3wmyoIw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=sD84pO/Z; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=3ojEtW3h; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="sD84pO/Z"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="3ojEtW3h" From: Nam Cao DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1717791734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Cn6XVXZM59Nth6p5tsQDc4XnTOplZUQTrnvegHUFwrU=; b=sD84pO/ZxF8vHvHfZgaOrW5D7kvyq5EI0jJbj4W+SN6ILAClGy5VssRHErCgGiHyp/NwXO OZnpD5JzqSFGWBiat2vuhQB4gv+G0m1PrtfMfafLZDdtPvMeYzJc5IflhGoLSWb8nS8wjt kJxyansVjaEjcaPglhJjXow7vTGq2KNE3FUU8PwsPnJsEz+U+lmyOVSXoaiSAlMvvII/6m k7kxbe5pAKDnVaG9qF4tpQIuGjB6S0rlGDKPQN7uGHI2vG7cMEc4iE3ClM+DExPnVhM7iC 25S7NRNQBIZ7/1eQ8rI9/dWg7InxsXNoQPcxiQvp7GVnNOD1/0d5iPkEUqdbBw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1717791734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Cn6XVXZM59Nth6p5tsQDc4XnTOplZUQTrnvegHUFwrU=; b=3ojEtW3hB0mfLXr+O+vmKQZ403TBBNLnM77VmV5V/6nREtIuy9sp4RkPWThWftXATWKLaI RaWPtBh1X93IkXBQ== To: Alexandre Ghiti , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 2/8] riscv: don't export va_kernel_pa_offset in vmcoreinfo for XIP kernel Date: Fri, 7 Jun 2024 22:22:07 +0200 Message-Id: <8f8760d3f9a11af4ea0acbc247e4f49ff5d317e9.1717789719.git.namcao@linutronix.de> In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The crash utility uses va_kernel_pa_offset to translate virtual addresses. This is incorrect in the case of XIP kernel, because va_kernel_pa_offset is not the virtual-physical address offset (yes, the name is misleading; this variable will be removed for XIP in a following commit). Stop exporting this variable for XIP kernel. The replacement is to be determined, note it as a TODO for now. Signed-off-by: Nam Cao Reviewed-by: Alexandre Ghiti --- arch/riscv/kernel/vmcore_info.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/arch/riscv/kernel/vmcore_info.c b/arch/riscv/kernel/vmcore_inf= o.c index 6d7a22522d63..d5e448aa90e7 100644 --- a/arch/riscv/kernel/vmcore_info.c +++ b/arch/riscv/kernel/vmcore_info.c @@ -19,6 +19,13 @@ void arch_crash_save_vmcoreinfo(void) #endif #endif vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=3D0x%lx\n", KERNEL_LINK_A= DDR); +#ifdef CONFIG_XIP_KERNEL + /* TODO: Communicate with crash-utility developers on the information to + * export. The XIP case is more complicated, because the virtual-physical + * address offset depends on whether the address is in ROM or in RAM. + */ +#else vmcoreinfo_append_str("NUMBER(va_kernel_pa_offset)=3D0x%lx\n", kernel_map.va_kernel_pa_offset); +#endif } --=20 2.39.2 From nobody Sun Dec 14 11:53:28 2025 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 1CE81145B1A for ; Fri, 7 Jun 2024 20:22:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717791737; cv=none; b=vBGfitE8OZ9JuOUxpEzESOIGSFl1QGeCsnOQKcWIyPQXZPqePKIee3NQQzltTXtHL2BSYqoz9ufXbdpMSsjKBabOXENRLwKxVANFG8dBkRz+iQGRxG40wcVFKNlALIs2YtrymklbViFKsYa9RApfokmoOy1LZTTrrtbHOqqFnGg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717791737; c=relaxed/simple; bh=AXLhTJOfOZbd5sWTxrT+P/JVlzoYysMbDWuTt1L3jiE=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=B+Lx4V4CbTJBfGv7MzlKoNckzbp+XqmrNDKl+9MxHsXbmI9GzeqZlIfaj4CE2STkOiGM3ygTfhruYj6OaWutj60ofKqfExhOX8GZLCxjooTynTfFpmAnxsf+z7QwoWCI9YtEFTriMtZtNmdhhFi7yRkS/0C3XM1sqP0frzk4v9k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=lAdxAtL1; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=L+bpi+80; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="lAdxAtL1"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="L+bpi+80" From: Nam Cao DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1717791734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4odO1GRTROf7xvMWOl3DqpmsPPjSYUQ/pXHn+xOw3Kc=; b=lAdxAtL1WO+adL+dYcUMR8vwNa0xTJsBJmhva63AYlFQDh9iB2KmPI0nzI7rctgnpzjFGp 1+qM69qhVTlhxLRahmln8BYKQ+cwLZp8ErCCWDQkQj8FO2i88zELxECIhL4SdC/Hj0l7gt R8qEf3b85XNA9e/c3Pczr06hu/y8zjSn252U827wfpMt8+eaXa1G4ommneqv3SV+x0qbGO VNRfEBde7XqQgX8+HepNazsYzG03lw4WOIQEwZvCsxJJzBukiRkumfLWVuI7FG/ky5hfx2 RSiJVqD4cHzop2bkP4hf+GuicVGkvaa3KFZFVfuz9GASY+igGnOBEFzlJlyh3Q== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1717791734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4odO1GRTROf7xvMWOl3DqpmsPPjSYUQ/pXHn+xOw3Kc=; b=L+bpi+80qMhsxa1grxAhSboftzk0iStipUSm9Wd4glNMTF1wlfW63xioVkOhA8Hn8lFmca mHo+MnwYL/aHfjAw== To: Alexandre Ghiti , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 3/8] riscv: replace misleading va_kernel_pa_offset on XIP kernel Date: Fri, 7 Jun 2024 22:22:08 +0200 Message-Id: <84e5d005c1386d88d7b2531e0b6707ec5352ee54.1717789719.git.namcao@linutronix.de> In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On XIP kernel, the name "va_kernel_pa_offset" is misleading: unlike "normal" kernel, it is not the virtual-physical address offset of kernel mapping, it is the offset of kernel mapping's first virtual address to first physical address in DRAM, which is not meaningful because the kernel's first physical address is not in DRAM. For XIP kernel, there are 2 different offsets because the read-only part of the kernel resides in ROM while the rest is in RAM. The offset to ROM is in kernel_map.va_kernel_xip_pa_offset, while the offset to RAM is not stored anywhere: it is calculated on-the-fly. Remove this confusing "va_kernel_pa_offset" and add "va_kernel_xip_data_pa_offset" as its replacement. This new variable is the offset of virtual mapping of the kernel's data portion to the corresponding physical addresses. With the introduction of this new variable, also rename va_kernel_xip_pa_offset -> va_kernel_xip_text_pa_offset to make it clear that this one is about the .text section. Signed-off-by: Nam Cao Reviewed-by: Alexandre Ghiti --- arch/riscv/include/asm/page.h | 29 +++++++++++++++++++++-------- arch/riscv/mm/init.c | 6 ++++-- 2 files changed, 25 insertions(+), 10 deletions(-) diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h index 115ac98b8d72..b1fcf0d733c4 100644 --- a/arch/riscv/include/asm/page.h +++ b/arch/riscv/include/asm/page.h @@ -112,11 +112,13 @@ struct kernel_mapping { /* Offset between linear mapping virtual address and kernel load address = */ unsigned long va_pa_offset; /* Offset between kernel mapping virtual address and kernel load address = */ - unsigned long va_kernel_pa_offset; - unsigned long va_kernel_xip_pa_offset; #ifdef CONFIG_XIP_KERNEL + unsigned long va_kernel_xip_text_pa_offset; + unsigned long va_kernel_xip_data_pa_offset; uintptr_t xiprom; uintptr_t xiprom_sz; +#else + unsigned long va_kernel_pa_offset; #endif }; =20 @@ -134,12 +136,18 @@ extern phys_addr_t phys_ram_base; #else void *linear_mapping_pa_to_va(unsigned long x); #endif + +#ifdef CONFIG_XIP_KERNEL #define kernel_mapping_pa_to_va(y) ({ \ unsigned long _y =3D (unsigned long)(y); \ - (IS_ENABLED(CONFIG_XIP_KERNEL) && _y < phys_ram_base) ? \ - (void *)(_y + kernel_map.va_kernel_xip_pa_offset) : \ - (void *)(_y + kernel_map.va_kernel_pa_offset + XIP_OFFSET); \ + (_y < phys_ram_base) ? \ + (void *)(_y + kernel_map.va_kernel_xip_text_pa_offset) : \ + (void *)(_y + kernel_map.va_kernel_xip_data_pa_offset); \ }) +#else +#define kernel_mapping_pa_to_va(y) ((void *)((unsigned long)(y) + kernel_m= ap.va_kernel_pa_offset)) +#endif + #define __pa_to_va_nodebug(x) linear_mapping_pa_to_va(x) =20 #ifndef CONFIG_DEBUG_VIRTUAL @@ -147,12 +155,17 @@ void *linear_mapping_pa_to_va(unsigned long x); #else phys_addr_t linear_mapping_va_to_pa(unsigned long x); #endif + +#ifdef CONFIG_XIP_KERNEL #define kernel_mapping_va_to_pa(y) ({ \ unsigned long _y =3D (unsigned long)(y); \ - (IS_ENABLED(CONFIG_XIP_KERNEL) && _y < kernel_map.virt_addr + XIP_OFFSET)= ? \ - (_y - kernel_map.va_kernel_xip_pa_offset) : \ - (_y - kernel_map.va_kernel_pa_offset - XIP_OFFSET); \ + (_y < kernel_map.virt_addr + XIP_OFFSET) ? \ + (_y - kernel_map.va_kernel_xip_text_pa_offset) : \ + (_y - kernel_map.va_kernel_xip_data_pa_offset); \ }) +#else +#define kernel_mapping_va_to_pa(y) ((unsigned long)(y) - kernel_map.va_ker= nel_pa_offset) +#endif =20 #define __va_to_pa_nodebug(x) ({ \ unsigned long _x =3D x; \ diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index 28f9c37443c8..313459329d16 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -1092,11 +1092,14 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa) kernel_map.phys_addr =3D (uintptr_t)CONFIG_PHYS_RAM_BASE; kernel_map.size =3D (uintptr_t)(&_end) - (uintptr_t)(&_start); =20 - kernel_map.va_kernel_xip_pa_offset =3D kernel_map.virt_addr - kernel_map.= xiprom; + kernel_map.va_kernel_xip_text_pa_offset =3D kernel_map.virt_addr - kernel= _map.xiprom; + kernel_map.va_kernel_xip_data_pa_offset =3D kernel_map.virt_addr - kernel= _map.phys_addr + + (uintptr_t)&_sdata - (uintptr_t)&_start; #else kernel_map.page_offset =3D _AC(CONFIG_PAGE_OFFSET, UL); kernel_map.phys_addr =3D (uintptr_t)(&_start); kernel_map.size =3D (uintptr_t)(&_end) - kernel_map.phys_addr; + kernel_map.va_kernel_pa_offset =3D kernel_map.virt_addr - kernel_map.phys= _addr; #endif =20 #if defined(CONFIG_64BIT) && !defined(CONFIG_XIP_KERNEL) @@ -1118,7 +1121,6 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa) */ kernel_map.va_pa_offset =3D IS_ENABLED(CONFIG_64BIT) ? 0UL : PAGE_OFFSET - kernel_map.phys_addr; - kernel_map.va_kernel_pa_offset =3D kernel_map.virt_addr - kernel_map.phys= _addr; =20 /* * The default maximal physical memory size is KERN_VIRT_SIZE for 32-bit --=20 2.39.2 From nobody Sun Dec 14 11:53:28 2025 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 1CDB719D89B for ; Fri, 7 Jun 2024 20:22:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717791738; cv=none; b=cKyvjZjI0m0DjCkpJo4czbn2HwbeEH4QvTl/um+j5CTHKBLD6hf5asbUywGCqJkdu5E2Lr94hsyR1lNrEYgWkNm6ZT5qwJiCD0MYVgWkYZtcSt5PeC/rAuR0LTF9Eb+poVKWUCSJwvTumpAIfN1mP2fxPrUGkkroOJMwmnhOvD8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717791738; c=relaxed/simple; bh=4itJeOheO3JCFGYjJsZp2HHj1O9EEO4G3V4kY2AsiVY=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=HQJDACHUU8r+Y4IrleV/8QDP6UtEPmE+O5NlZlYOQDFkGtRREKwRfR1sbRzuQK5OonHyWbAPfX8EWP+TK9TYEDm4zSy0Raz3fNctEC+ktUVVnbRKMsfyEv2jroDySTHOgXeOsjtHsEw+9SghgCrXrVhKYpZegFd8PvAnbFDzYDI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=gxJTMEjj; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=nofRIHje; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="gxJTMEjj"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="nofRIHje" From: Nam Cao DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1717791734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xAfTfmpszFUN8R3pQgNHXaFB8SYv5tBzsg3wc1Daekc=; b=gxJTMEjjVsWUXg8QWo8gxk6k6dsK1gOSK8tiVKXP5qTp34PYDSnja7IWgElhx75fYN8tr7 l602j9hesKQoFFE2N+sl62RFmCbIAC0er2w8jwhGeizfJq0wTou/jxVaJ1FadOiltK1VKX mcw5Rniv4bObsJlZxU8kgMXDshp4S1YlKAr9hSGIYjtvYhtc0GdU02f39XNFsYilbM8wPw 8312nbySFzXFPtx2L5HiG5xwvnjOED8vhNJIuLQKM0leerlH6gIu/tvcYgkthd7LTenxky hpaTZounjSwIpPUegA0PssykWkUF8peu71Z3b+LJhdcbDj53w6X7d92mtiyK2g== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1717791734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xAfTfmpszFUN8R3pQgNHXaFB8SYv5tBzsg3wc1Daekc=; b=nofRIHje+QL9kJv7xuUmmYgeTzznlDF8UquGUkvpWA1FtPDrwMFpZchdLaVXLfcVSs9T73 K/C9iB3wE69jeUCg== To: Alexandre Ghiti , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 4/8] riscv: drop the use of XIP_OFFSET in XIP_FIXUP_OFFSET Date: Fri, 7 Jun 2024 22:22:09 +0200 Message-Id: In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" XIP_OFFSET is the hard-coded offset of writable data section within the kernel. By hard-coding this value, the read-only section of the kernel (which is placed before the writable data section) is restricted in size. As a preparation to remove this hard-coded macro XIP_OFFSET entirely, stop using XIP_OFFSET in XIP_FIXUP_OFFSET. Instead, use CONFIG_PHYS_RAM_BASE and _sdata to do the same thing. While at it, also add a description for XIP_FIXUP_OFFSET. Signed-off-by: Nam Cao Reviewed-by: Alexandre Ghiti --- arch/riscv/include/asm/xip_fixup.h | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/riscv/include/asm/xip_fixup.h b/arch/riscv/include/asm/xi= p_fixup.h index b65bf6306f69..9ed2cfae09e0 100644 --- a/arch/riscv/include/asm/xip_fixup.h +++ b/arch/riscv/include/asm/xip_fixup.h @@ -9,8 +9,19 @@ =20 #ifdef CONFIG_XIP_KERNEL .macro XIP_FIXUP_OFFSET reg - REG_L t0, _xip_fixup + /* Fix-up address in Flash into address in RAM early during boot before + * MMU is up. Because generated code "thinks" data is in Flash, but it + * is actually in RAM (actually data is also in Flash, but Flash is + * read-only, thus we need to use the data residing in RAM). + * + * The start of data in Flash is _sdata and the start of data in RAM is + * CONFIG_PHYS_RAM_BASE. So this fix-up essentially does this: + * reg +=3D CONFIG_PHYS_RAM_BASE - _start + */ + li t0, CONFIG_PHYS_RAM_BASE add \reg, \reg, t0 + la t0, _sdata + sub \reg, \reg, t0 .endm .macro XIP_FIXUP_FLASH_OFFSET reg la t0, __data_loc @@ -19,7 +30,6 @@ add \reg, \reg, t0 .endm =20 -_xip_fixup: .dword CONFIG_PHYS_RAM_BASE - CONFIG_XIP_PHYS_ADDR - XIP_OFFSET _xip_phys_offset: .dword CONFIG_XIP_PHYS_ADDR + XIP_OFFSET #else .macro XIP_FIXUP_OFFSET reg --=20 2.39.2 From nobody Sun Dec 14 11:53:28 2025 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 20D8F15381B for ; Fri, 7 Jun 2024 20:22:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717791741; cv=none; b=MWVCZoH0bIqgc19MUeOvUClzyALNh4attIZIaQYG5leertZPrZ01jVq6sPdUlj6gKF0zUPJTVLYJ+yNftio7TG7wBnogEj8++kNGZyvl4qaXR/IrrgCodteMz3wde/w5Ku1oGXA2QXNkG175S1RU2X7fphSPOrFYDQUUFAg1Q/4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717791741; c=relaxed/simple; bh=S3LKBRdYZ76UR5mU6mhYfYh8IKB/KBkG8xCM3TgV+vY=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=jDgG89/VOoQdsgfK4jwDrSg/0vuKprR6Oin+ZyYg1jk2XgqhdD42TQD2JS3o3FwvrPlwJCDQi4pBT65JRYBnfozbvPkvGSwLt+Nwv786j4alCsm0PBKyeJawrZiSK5QpxWnc7ZLVbFp721LQT5hfs9Q3O6VoovXGNTsBzh+1TAo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=mEqcFoqV; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=gDBFKNnG; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="mEqcFoqV"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="gDBFKNnG" From: Nam Cao DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1717791734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DbsnZTi3yzYGcTgPSKaSRSUxnZfcrNRyLlLmKPFRcq8=; b=mEqcFoqVjpXHIvQJzHnpy33A6eYLASQS9rK4xkGen/LQ6fhZnv+Ap785wROp0YvwD8FHU7 niKGv8x9Tk6bjiBkbMqWHx7aTIejL0Q/v+67iX5EsW6Nr8SNLpiDRAKoDnsc823a6WxVYk uxqWB1BI7+OZ9N2AJ+qdfCIgjWFsuZQya0s6/DqRY3F5sIGmwmBQytg9ToasdWeP33Cmt6 Td8LxG0z+CU/rjNEd7//nkHBh+g8CuYp9a5AAhRulQWmX32QDCA52nJsFgAtcluFleaDyn cFBOfrJWPcssBbXUtmJgPwLAqiwyBUF+y452lk5Iz7hETS57gUaAITAPT8zB1w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1717791734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DbsnZTi3yzYGcTgPSKaSRSUxnZfcrNRyLlLmKPFRcq8=; b=gDBFKNnGRevOYtiAVL7cWyH6dsm6ymR4UCm6nKm+VDXdqgBs8BzfgFefTbtv2zd6af76QU n80+Z688v6fHDwAw== To: Alexandre Ghiti , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 5/8] riscv: drop the use of XIP_OFFSET in XIP_FIXUP_FLASH_OFFSET Date: Fri, 7 Jun 2024 22:22:10 +0200 Message-Id: <7b3319657edd1822f3457e7e7c07aaa326cc2f87.1717789719.git.namcao@linutronix.de> In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" XIP_OFFSET is the hard-coded offset of writable data section within the kernel. By hard-coding this value, the read-only section of the kernel (which is placed before the writable data section) is restricted in size. As a preparation to remove this hard-coded macro XIP_OFFSET entirely, stop using XIP_OFFSET in XIP_FIXUP_FLASH_OFFSET. Instead, use __data_loc and _sdata to do the same thing. While at it, also add a description for XIP_FIXUP_FLASH_OFFSET. Signed-off-by: Nam Cao Reviewed-by: Alexandre Ghiti --- arch/riscv/include/asm/xip_fixup.h | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/arch/riscv/include/asm/xip_fixup.h b/arch/riscv/include/asm/xi= p_fixup.h index 9ed2cfae09e0..f3d56299bc22 100644 --- a/arch/riscv/include/asm/xip_fixup.h +++ b/arch/riscv/include/asm/xip_fixup.h @@ -24,13 +24,21 @@ sub \reg, \reg, t0 .endm .macro XIP_FIXUP_FLASH_OFFSET reg + /* In linker script, at the transition from read-only section to + * writable section, the VMA is increased while LMA remains the same. + * (See in linker script how _sdata, __data_loc and LOAD_OFFSET is + * changed) + * + * Consequently, early during boot before MMU is up, the generated code + * reads the "writable" section at wrong addresses, because VMA is used + * by compiler to generate code, but the data is located in Flash using + * LMA. + */ + la t0, _sdata + sub \reg, \reg, t0 la t0, __data_loc - REG_L t1, _xip_phys_offset - sub \reg, \reg, t1 add \reg, \reg, t0 .endm - -_xip_phys_offset: .dword CONFIG_XIP_PHYS_ADDR + XIP_OFFSET #else .macro XIP_FIXUP_OFFSET reg .endm --=20 2.39.2 From nobody Sun Dec 14 11:53:28 2025 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 2448E153BF6 for ; Fri, 7 Jun 2024 20:22:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717791740; cv=none; b=WobZyfo0Okc5thKyvNxuRZ9n1OsteYlFwD/ohGptvYJ0/E5pQHyk9Y5xezjuzH3HvqOEbvINmVLW7/+dpm8D7VtCo1Y9UNHcqflxST1yz2XeWEBQjjUJTTPipgQ9OBmD319ahhE8GHe1wT7QhJjwej725rIJuhcNq42UpYjnKNQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717791740; c=relaxed/simple; bh=rqgphNpvAIswvOtuYW+jmZOKl/Ada8Dg9FW1BkMfDMY=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=FwJEfeQrNaDiEbvMhsPb8GqneMJ7xqIX2MiUSwJeQva8fDh2NDXRagCziX1wXw/tmjegOsVopZmFvBtrfL6aB7kdB4MUhLU43BDd1ExQyaIRfkB/7OuYRGyJFp7Al3l0iV05lox2rgkYNzCqVnDYQ9nT1KTDDWT7t9HQz5Rn6XE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=cQzPkJdt; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=baW3tS6A; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="cQzPkJdt"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="baW3tS6A" From: Nam Cao DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1717791734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TP0ssdDAE0NqzBzFQW76UUCVj0BXnEtRoVuuQq7wR+A=; b=cQzPkJdtRWilbFwWhEzmOk8wKwdQTdbrjtndb3Y+dC72TGNip7QyeYIf1ym/rDYhKOvXAV g994mSyBhfaKP0VLrAYutCQeOoCRfCg3/c6N7Ooiiq4J42a9dL9ikGhDy2gI6+VwOgig6o LYu3oKF2qoHLTrsZH8sR0rxBHpp8GagcYhHJIsZXck56+Cdwfd0Aa8CQEFLVTWCk9QjPh0 q+Iqu8K+S5rKHIJEE14bL/y5+hvGLNoNxkVCmmTGF6o41jKT3C/ObAx1aCE9nVgByBznCn NOGPBxuG1TyxM5shHTfhaE3dQBGBZBWyROq3eLWp0auUC3K3Use7X6JyaPCRjQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1717791734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TP0ssdDAE0NqzBzFQW76UUCVj0BXnEtRoVuuQq7wR+A=; b=baW3tS6AU1ouireVhMZXJaC7HqFegaRe4WIoi/evjK5RZHILiI6VHVnu0W4qgXHjbRUBRY DcR18wEhRuGd6mDA== To: Alexandre Ghiti , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 6/8] riscv: drop the use of XIP_OFFSET in kernel_mapping_va_to_pa() Date: Fri, 7 Jun 2024 22:22:11 +0200 Message-Id: <644c13d9467525a06f5d63d157875a35b2edb4bc.1717789719.git.namcao@linutronix.de> In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" XIP_OFFSET is the hard-coded offset of writable data section within the kernel. By hard-coding this value, the read-only section of the kernel (which is placed before the writable data section) is restricted in size. As a preparation to remove this hard-coded macro XIP_OFFSET entirely, remove the use of XIP_OFFSET in kernel_mapping_va_to_pa(). The macro XIP_OFFSET is used in this case to check if the virtual address is mapped to Flash or to RAM. The same check can be done with kernel_map.xiprom_sz. Signed-off-by: Nam Cao Reviewed-by: Alexandre Ghiti --- arch/riscv/include/asm/page.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h index b1fcf0d733c4..cda4a917f90a 100644 --- a/arch/riscv/include/asm/page.h +++ b/arch/riscv/include/asm/page.h @@ -159,7 +159,7 @@ phys_addr_t linear_mapping_va_to_pa(unsigned long x); #ifdef CONFIG_XIP_KERNEL #define kernel_mapping_va_to_pa(y) ({ \ unsigned long _y =3D (unsigned long)(y); \ - (_y < kernel_map.virt_addr + XIP_OFFSET) ? \ + (_y < kernel_map.virt_addr + kernel_map.xiprom_sz) ? \ (_y - kernel_map.va_kernel_xip_text_pa_offset) : \ (_y - kernel_map.va_kernel_xip_data_pa_offset); \ }) --=20 2.39.2 From nobody Sun Dec 14 11:53:28 2025 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 22506153BC3 for ; Fri, 7 Jun 2024 20:22:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717791740; cv=none; b=RRgA9GuU6Wv4bT3pPcDf4vl49djAO8ZfdmW4gKvlT+3I5tleRvcG7q92viLjKiY0uwCu+VMoBDd1dwTiamggvpljLx0IlLSht753+O1jrkeRwgGnpx+dLkOL6JKbdta3WXaLXeenPb50SjHMKnFppvGBhm7geCb0yOZjy4gs+J4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717791740; c=relaxed/simple; bh=CnPSiJoSkTaS4DgxuVepbWdO7rowLFCL7+5optFOhBE=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=mEwJyXvKejkh+LbUip1cWXghIQX6ToZJTl2yyFKWAkgbE4N0ISkAg2nrNOQXVYAmeKU4MiSYX2aD79QO0VCF0eqlCc+KbY4TwJKR7/4woJ49dI35sVSS4GZkl+R80aB030579qhtENbKFOardCkjZjtAXCaNj9EWxnMghsWEzSI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=jV4r27iO; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=qenheITo; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="jV4r27iO"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="qenheITo" From: Nam Cao DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1717791734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=y4FmsaK4U8owu4NlSDzmS6G8DVihDPJxkQgSL8xnqno=; b=jV4r27iONhJVERHB641eznAaftrwZ3nE682uV9gC1aGX3evxbgEtI3+I/GGIFZOgjpwiHX jrivhNjIULLbcTEF1ebUWj0KfocGBOpUnJ089SgjLwdKHrT3YqY/Eg0SXgoahKrD73OQPD GIPo3UKx7rqQ8OQfdvFUdf7X8OHayoEhJvPcmX6BDOlSxCWNVz6CkE8p3Fk92DtWshTiPF dt03h8kY0i0/VeSoJX638ThLxRh0Z3R5ck0NRVVs8N5T4i5pkp03gk2RhX4GYCP2ODf4pk b/rBf/p5UzcV/U6PLxXYHL0ZFnOUVb7oknY6vFnqE2fmMzHNT9Mjn98ZwcXy8Q== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1717791734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=y4FmsaK4U8owu4NlSDzmS6G8DVihDPJxkQgSL8xnqno=; b=qenheITowqvS4kQkmh3FtMet7WUSPFv4Sdzt965PbpQbng2mrMAKUNPxeXEZyrFEa0dnT6 byAMvr7yCjRM4vBg== To: Alexandre Ghiti , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 7/8] riscv: drop the use of XIP_OFFSET in create_kernel_page_table() Date: Fri, 7 Jun 2024 22:22:12 +0200 Message-Id: <4ea3f222a7eb9f91c04b155ff2e4d3ef19158acc.1717789719.git.namcao@linutronix.de> In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" XIP_OFFSET is the hard-coded offset of writable data section within the kernel. By hard-coding this value, the read-only section of the kernel (which is placed before the writable data section) is restricted in size. As a preparation to remove this hard-coded value entirely, stop using XIP_OFFSET in create_kernel_page_table(). Instead use _sdata and _start to do the same thing. Signed-off-by: Nam Cao Reviewed-by: Alexandre Ghiti --- arch/riscv/mm/init.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index 313459329d16..b7b6affd4b79 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -911,7 +911,7 @@ static void __init relocate_kernel(void) static void __init create_kernel_page_table(pgd_t *pgdir, __always_unused bool early) { - uintptr_t va, end_va; + uintptr_t va, start_va, end_va; =20 /* Map the flash resident part */ end_va =3D kernel_map.virt_addr + kernel_map.xiprom_sz; @@ -921,10 +921,11 @@ static void __init create_kernel_page_table(pgd_t *pg= dir, PMD_SIZE, PAGE_KERNEL_EXEC); =20 /* Map the data in RAM */ + start_va =3D kernel_map.virt_addr + (uintptr_t)&_sdata - (uintptr_t)&_sta= rt; end_va =3D kernel_map.virt_addr + kernel_map.size; - for (va =3D kernel_map.virt_addr + XIP_OFFSET; va < end_va; va +=3D PMD_S= IZE) + for (va =3D start_va; va < end_va; va +=3D PMD_SIZE) create_pgd_mapping(pgdir, va, - kernel_map.phys_addr + (va - (kernel_map.virt_addr + XIP_OFFSET)), + kernel_map.phys_addr + (va - start_va), PMD_SIZE, PAGE_KERNEL); } #else --=20 2.39.2 From nobody Sun Dec 14 11:53:28 2025 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 DCDEF1527BC for ; Fri, 7 Jun 2024 20:22:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717791740; cv=none; b=N3ogryFuRRBwCr5jYAh6nAGHqB9fOEMbBBCpfL1dBBsCtJYP7PyTL1sB/4JHlSY5LES0vW6ePvrpV/AnL+p9qMFSdTk8DFNWSWwRaQklpkI63yEhQrC3dQzTmjOptr0SvwXr9FA1wg/CcXNIBQHLzD0o+IDQvpBv2otjujUtQkM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717791740; c=relaxed/simple; bh=b3kfaE3B5DqZl7RCPFsX8KN1jUPY+NVq9KI1mO6MnV8=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=WCK3f0py09WEzGocR3R68zfHckPQdYvHQJ5MfSzpFmfi7Y8fK/xS0sKHkIRd2vMJaWXPTmWsmHIkiCaheOxHs7ytE08ROll7STybeYi49g9RT5GNui/5tB7m9Zyd3iOjUPUhjy8rGJFCmZ5BSndPOl+l9iODRkkTnmZe7e6C0BE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=0npk3eVU; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=pAOWJZp1; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="0npk3eVU"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="pAOWJZp1" From: Nam Cao DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1717791734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QlQGR+tGoioFd255pa4F2M3do0QPDjAAVJR0Ox/2Zbw=; b=0npk3eVUOmUI1nJgJEXVN/ccbreM702IcCn9WYf4K/Oxj9tGeMxddKkJDGTLsUd6jU2Hld 86Xue89Ax+FDFdr9bi4qq0TZILDFEK4O0vrkSSqjw0jrpsUrochYd1ry6G8v8Lp3515Rpi 9Cn3A2N9JjNeldDor7FOPGDDYDVkBHeClap9PF2sTvYFqwn/F7PxWsn+/8ABx8JEdvzbGE PX6YLMMZVGxgy+nAhy0qy6DK607Dm1xO0FXBnf5odNFkK+MwvNBSvHhaM36oP+IVSTu7R0 rgtqlU1JZaXDFC4dQJbF6bx8ZEJ21UxJuL5aMpyOjGfOAkB7alyW5ynRxbMVXQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1717791734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QlQGR+tGoioFd255pa4F2M3do0QPDjAAVJR0Ox/2Zbw=; b=pAOWJZp1PU/dlsrZNLVkbeFP89DsN/O4sOSeJ+S3UZsBgLwdnT58Oc5YLEFIvS5di+cZG4 vW6wJ5f0wxgfC1Cg== To: Alexandre Ghiti , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 8/8] riscv: remove limit on the size of read-only section for XIP kernel Date: Fri, 7 Jun 2024 22:22:13 +0200 Message-Id: <3bf3a77be10ebb0d8086c028500baa16e7a8e648.1717789719.git.namcao@linutronix.de> In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" XIP_OFFSET is the hard-coded offset of writable data section within the kernel. By hard-coding this value, the read-only section of the kernel (which is placed before the writable data section) is restricted in size. This causes build failures if the kernel gets too big [1]. Remove this limit. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202404211031.J6l2AfJk-lkp@int= el.com [1] Signed-off-by: Nam Cao Reviewed-by: Alexandre Ghiti --- arch/riscv/include/asm/pgtable.h | 7 ------- arch/riscv/include/asm/set_memory.h | 2 +- arch/riscv/kernel/vmlinux-xip.lds.S | 5 +++-- 3 files changed, 4 insertions(+), 10 deletions(-) diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgta= ble.h index 1bc103aa9b74..bf4afffe0c53 100644 --- a/arch/riscv/include/asm/pgtable.h +++ b/arch/riscv/include/asm/pgtable.h @@ -107,13 +107,6 @@ =20 #endif =20 -#ifdef CONFIG_XIP_KERNEL -#define XIP_OFFSET SZ_32M -#define XIP_OFFSET_MASK (SZ_32M - 1) -#else -#define XIP_OFFSET 0 -#endif - #ifndef __ASSEMBLY__ =20 #include diff --git a/arch/riscv/include/asm/set_memory.h b/arch/riscv/include/asm/s= et_memory.h index ec11001c3fe0..ab92fc84e1fc 100644 --- a/arch/riscv/include/asm/set_memory.h +++ b/arch/riscv/include/asm/set_memory.h @@ -46,7 +46,7 @@ bool kernel_page_present(struct page *page); =20 #endif /* __ASSEMBLY__ */ =20 -#ifdef CONFIG_STRICT_KERNEL_RWX +#if defined(CONFIG_STRICT_KERNEL_RWX) || defined(CONFIG_XIP_KERNEL) #ifdef CONFIG_64BIT #define SECTION_ALIGN (1 << 21) #else diff --git a/arch/riscv/kernel/vmlinux-xip.lds.S b/arch/riscv/kernel/vmlinu= x-xip.lds.S index 8c3daa1b0531..a7611789bad5 100644 --- a/arch/riscv/kernel/vmlinux-xip.lds.S +++ b/arch/riscv/kernel/vmlinux-xip.lds.S @@ -14,6 +14,7 @@ #include #include #include +#include =20 OUTPUT_ARCH(riscv) ENTRY(_start) @@ -65,10 +66,10 @@ SECTIONS * From this point, stuff is considered writable and will be copied to RAM */ __data_loc =3D ALIGN(PAGE_SIZE); /* location in file */ - . =3D KERNEL_LINK_ADDR + XIP_OFFSET; /* location in memory */ + . =3D ALIGN(SECTION_ALIGN); /* location in memory */ =20 #undef LOAD_OFFSET -#define LOAD_OFFSET (KERNEL_LINK_ADDR + XIP_OFFSET - (__data_loc & XIP_OFF= SET_MASK)) +#define LOAD_OFFSET (KERNEL_LINK_ADDR + _sdata - __data_loc) =20 _sdata =3D .; /* Start of data section */ _data =3D .; --=20 2.39.2