From nobody Mon Sep 28 22:30:44 2026 Received: from mail-ej2-f43.google.com (mail-ej2-f43.google.com [74.125.228.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C82AB4F55B5 for ; Mon, 28 Sep 2026 20:08:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.228.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790626128; cv=none; b=qg/mcW5T7lMmnZjbo1zEU3SyfalfSPMhCQe40QH0sj1WWPIifCX+yy85HSCZLeCZeQC8jns6zXtLun+X5NudsQ+WwpzjIqkTz2hmeoBWr4qdbz4jkwtzkAdYASNhlspa0twFRqafGaDrSaq1OHd1LAspc/gSmZau0BmcTNpKd4c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790626128; c=relaxed/simple; bh=KbFTqf0Stipa6Z0Bf79nWzA2T/N8nR0vSGeB4CqZjYU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uc4b8PSvsn0yksN0nhKEj0CTK1+GbUu7K067iRumCYyUN/I/2IiHHVJccTcZfTuHaenyOExT3fSIJAiFTSf8QEE3WcQmnxsxW4r6U+dXeFo0JeXyprDyATJ9q0hkHMa5a119psjDwLIkDex28V5BvpsVeFinItwNzy1tYQxaTvw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=dPlDZWmN; arc=none smtp.client-ip=74.125.228.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dPlDZWmN" Received: by mail-ej2-f43.google.com with SMTP id a640c23a62f3a-c2a8b9acbc6so506684466b.0 for ; Mon, 28 Sep 2026 13:08:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790626125; x=1791230925; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=CtakEnWLArPo5Q59HM8M0ssZyLg6kVbX40sG8XoXT0s=; b=dPlDZWmN54mISqwprU6ivV+m6IM8HfS0HaAHfJQ1JIWc9NeZ11rsjQ6/3rd9PuJMRN l8jXha1T7I2OhDifAF/w/BA5kXDCsLX8merYYtgroLpB7TzRTrDPAtyLqR8KGLVnxZZ0 H3VBDxzUmLYghMxQxQ9thd10pTWiV2upPL7qNqG18qt7nUSkG4WcSG8BuoPWK6JUcFnh Kbgrq8HMtB1o7klkC1uHCojzQoRCBprJhThCyMOuPCKbaDCHz8IYv1x/sWWlxQ9eVf+E E0QDAAU6oo6gKyYWrNsixGWxJeYyj5m+RRz5rHudzaYl47EMckcdgcQKRtLq+3RoRNT1 UDqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790626125; x=1791230925; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=CtakEnWLArPo5Q59HM8M0ssZyLg6kVbX40sG8XoXT0s=; b=zO4SQeJ8g3QU5yhGEFN/4LqhheK6dpkHTYSc2a5QEpv/svtlc2c1eC15KbxAhM1TcX lz5U3LJL3VFWHsz7YrjX7S6o+krHrHKPd3UrpFpew7TzMl2smSdcYhzH4zoEeJiwDNES 0+lCpBZlyhqQ1BEFv/KeAq5h6UVgqZoKQ4ubafiYQaWJf75Ppy7xhHVwcZKaNI5FYDNv p8ln0BdF4AVH4l1tWkqVXGmXL7KxYM/ticSD7Gc0mMvtUnycVjRDQ0HkGO9Gq+1CvWAm BEJ7pDKzQMzVarAl15c11o9NROCsq+ZSX78Ih0rnNfz33BQN+A9+NeHW6j6mw3F/eesI 94nQ== X-Forwarded-Encrypted: i=1; AKwUvBwns35tQ0lJ+8MaZcVzsPAPme04gGqUzoT4Ob5xMlwxQyrLO1qHn0vC5KC1HAvkF+6C7Lud4q7KmpuZGYw=@vger.kernel.org X-Gm-Message-State: AFuF++kpoA8CqLJTUCx736NcxRjkOti0LSvy4hezQB7v/X8LzxP0iMg0 K2BmCytWij3oVGA0t5lGCHfDWt2YFjRb9fsgGjQl5H2wvnNwJWY8U+Xw X-Gm-Gg: AYBFou3hHFPTD/qorRp49rD2DBrTMiHJ54Wb4/RxwfcyKL82SW/myQzdr1tbIqBzhHR 3uR9APQwhGyIvdNqVko7i5BW4qDXlMHgcCyCuERAoUwJqfUk+s5+okSw4IZ9YYTyJFu8J8OkVwj af/vhq59bYDJvYXD3otkJDOjb4Kf0BI/Z1cdl2A5BD21lns8EpNbTCppZQxk59okZc/MFz/7kSg x8xCxrGc3cuRO1+/y5EWT26Wss+I4SHuhwjI1jUcqcO7dKUkDhsRR9h0nBhaJqzj22Z29lZM03+ aw+Z+ZhZz4m5Nz1JhsKstMPu+430HL1gpYU7JXLH6awTedjXRlNMifQOgh9mQ/4L3tcPdUscKms 1pmDJ8KAYNVhCU7Oz0G7414Uk2LDui4oQvDPxwnpcgAnt5bS2DMb+TMMJMpgaIr0yoeVqlbiFte EGYup/lkfjRFGQvCsmfqIN2HGc05y5Dh0QlTffKhQ5EcQSz2KSL7rkr1g6hxesCI3vQA6VlvLkM ZHuXdanymafG0vbd6iQGuoST5NHrN6t8Q8iyqqs X-Received: by 2002:a17:907:7ba5:b0:c25:8c05:902f with SMTP id a640c23a62f3a-c2ac230affbmr1172846066b.13.1790626125092; Mon, 28 Sep 2026 13:08:45 -0700 (PDT) Received: from buildhost.darklands.se ([2001:9b1:ff:d701:51eb:176f:63d9:53f8]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2ae76abc3asm509778166b.37.2026.09.28.13.08.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Sep 2026 13:08:44 -0700 (PDT) From: Magnus Lindholm To: davem@davemloft.net, andreas@gaisler.com Cc: linmag7@gmail.com, sam@ravnborg.org, sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 1/3] sparc32: honour phys_base in the viking cache flush routines Date: Mon, 28 Sep 2026 22:06:22 +0200 Message-ID: <55357ed4f6270c81595a018af2fbe391d8b912ab.1790548064.git.linmag7@gmail.com> X-Mailer: git-send-email 2.53.0 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" viking_flush_page() and viking_mxcc_flush_page() derive the physical address of the page they are asked to flush by subtracting PAGE_OFFSET from the kernel virtual address: sethi %hi(PAGE_OFFSET), %g2 sub %o0, %g2, %g3 That is only the physical address when phys_base is zero. The C side spells the same conversion __pa(), which adds phys_base, and every caller passes a kernel virtual address expecting exactly that. With a kernel loaded away from the start of RAM the two disagree by phys_base. viking_flush_page() then compares cache tags against the wrong page and flushes nothing, and viking_mxcc_flush_page() streams a page that is phys_base lower than the one it was given, so the intended lines stay dirty in the cache while unrelated ones are pushed out. The visible effect is that anything relying on a flush to make memory visible to another bus master silently keeps working from stale data. On a SPARCstation 20 this shows up as every SCSI transfer failing with a DMA error: iommu_flush_iotlb() cannot get the IOPTEs out to RAM, so the IOMMU walks stale entries and the ESP DMA faults. Add phys_base, so these agree with __pa() again. No change when phys_base is zero, which is why this went unnoticed. Reviewed-by: Sam Ravnborg Signed-off-by: Magnus Lindholm Message-ID: <20260928002035.1-2-linmag7@gmail.com> --- arch/sparc/mm/viking.S | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/sparc/mm/viking.S b/arch/sparc/mm/viking.S index 48f062de7a7f..8b4e251bbba2 100644 --- a/arch/sparc/mm/viking.S +++ b/arch/sparc/mm/viking.S @@ -38,6 +38,9 @@ sun4dsmp_flush_tlb_spin: viking_flush_page: sethi %hi(PAGE_OFFSET), %g2 sub %o0, %g2, %g3 + sethi %hi(phys_base), %g2 + ld [%g2 + %lo(phys_base)], %g2 + add %g3, %g2, %g3 ! + phys_base =3D physical address srl %g3, 12, %g1 ! ppage >> 12 =20 clr %o1 ! set counter, 0 - 127 @@ -91,6 +94,9 @@ viking_flush_page: viking_mxcc_flush_page: sethi %hi(PAGE_OFFSET), %g2 sub %o0, %g2, %g3 + sethi %hi(phys_base), %g2 + ld [%g2 + %lo(phys_base)], %g2 + add %g3, %g2, %g3 ! + phys_base =3D physical address sub %g3, -PAGE_SIZE, %g3 ! ppage + PAGE_SIZE sethi %hi(MXCC_SRCSTREAM), %o3 ! assume %hi(MXCC_SRCSTREAM) =3D=3D %hi(MX= CC_DESTSTREAM) mov 0x10, %g2 ! set cacheable bit --=20 2.43.0 From nobody Mon Sep 28 22:30:44 2026 Received: from mail-ej2-f42.google.com (mail-ej2-f42.google.com [74.125.228.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D16DB4F6473 for ; Mon, 28 Sep 2026 20:08:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.228.170 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790626129; cv=none; b=J6lp2gJiAc+h4rSyCGDl5/wbBwEfNfdyrer16hAYFgmC1UGxbVlt6TpNA4OWVbGtPBl4MoVzl1cjvv5d9CvDxZaxt36ZtkbY2Z2CRCS7ycabBHNC/kWJZMp33pp1oc128jV8B6J+nNYDDr6Orv/G+wSvcOYm8CZJmd0+nFHKU3Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790626129; c=relaxed/simple; bh=d2MUplHsS8U4FJAMDoym0CNaIjbOWLHpN+BVoJXXMdE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rEHdZ/h4Kfbdpo0O0N6e25jOvS7I04FacwQ7LEr3x7Tly1OYCbUr/OnSk/ONlMd8PzAMoWHC0sSx0xvr7ObssjEMaXeFs3DqqjCaOadIMt82wiNaxSzVYcMFF1o8mtnOmgedksJaDU9skW5tBAi14uQgorJihohSDn3th4hzdLQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=pgQgfz1C; arc=none smtp.client-ip=74.125.228.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="pgQgfz1C" Received: by mail-ej2-f42.google.com with SMTP id a640c23a62f3a-c2da4eea067so282748566b.3 for ; Mon, 28 Sep 2026 13:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790626126; x=1791230926; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ZmSflQBXftp4HXe4zrTMF1QW5LZc3st1xkIXknkEjYs=; b=pgQgfz1CGdfgc5nOYb0VXubQ35hGbzuEGpEbcKvrjScIOHRHpLn67jGjoHIkJl3pP7 LHqzNqG+DGuNUvTMqrjYNrEeT79QOG17nz1uqRK/6rHtf51ihXWt06gXPjQ5V/f9uAE3 bo6H7yJopSGCtA6as4mXuEghPR6mowA09xYCiJO0pEUVZQbKeptpSOVgwbC3r5sI+4gy 7pQKdZW6mKeWvZPfMacJHwRLF/8qnYtpLCvCoKd1Lgq5dBSs3F9t9vkZgwUoNw14jE2K BfVc6tJQJFgsI31k4sVhFyzUAjTNHb0futW7TAWn4OlhPXn1t5ThWEL/5SEcciDj8JBC F5Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790626126; x=1791230926; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=ZmSflQBXftp4HXe4zrTMF1QW5LZc3st1xkIXknkEjYs=; b=xNzOjNc1T2PZcj63DARU8H5FLHt2EJR628+3utKNMVfEKs9659vq9PSmRSdkwBxibL 5VMZirQKuICQ0SWmhgEYreYT/JII+xDAeAr2P+oOzLcJbCQ3wNGDMgeHvKtm8qvMCeDF 6PdnYjMxYkny4fxQGQdiWK/m4x6cWr712OHrtnIl4Y92RfjvmwrgEy4+l7keBSYIr3Z6 nH6sr4LhHHTn/3zAu6hlw5DJiZnMFveYeBMhslIzuxgpLcrwr0sP79DE8fjExsEqg8H5 g3fJxJpxiiQh+i8aevOeyTwWXNITuko+wpsgqGPvz5eKSMECjfzqntHUnfyNPPrNUV+R AsVg== X-Forwarded-Encrypted: i=1; AKwUvBxlwUUQ1nHG0GJA9iWLMH+KZoo/+JmOcaicfmFyVfHHQMZFMCWKQUXURoDkPTPf7wPuZbDUuj1GIUmvIug=@vger.kernel.org X-Gm-Message-State: AFq9FYLJAn/xp5ZiuVsS3L/wCdlSyQAl2Gz01jEJ6GHNxqJaUvJbxwaE dq1ELCR0xaC8yHmQ3RmHqGvyy4khdtvpiebEDbUHNRXhofa2vp1bYGv+ X-Gm-Gg: AYBFou1Hz7/OosRSOEAb/QhrRx+cvIav/+sRIGe8TZd/OAvNXLShZrpD1sino0py4C2 MbzMKEud+ucdTeX+CGiHe56sTd/Umf6LtWmqK3vIomts000NCsvKKnXm7/BejYHdyJ0oRWF1YsN YpWbjox0PFS3rOB9suLIcVBco8bz0ID0JVmneb5IiuOJkEO77oCtY2ht9OjVNdLTm+Ojl3DgXsU mH2KXiXpuIAkcKA3glG+jln74Y+mwaDXBpaipU4aVY7RdxK21b+MOafUYLQdJqw69tAl0MT70Ey hGXHD20DSAGAB1Zb+9a4OhVHEeVAhGnFka52GBr7vRaBgj+uAhTfh1D1AWr5tiUxuvIrFgHLL8o YU2zaZdinSFpB9NPwY4HQTBeEAPZDxD2AAZGB3iuwuqFmCbWgP6ZHYNxaJqDvHa+ke2xzx9pIJF 1nr783gH0H5V1H274Iyvi0gYgCmfpLs3iy5i3p32G0xIL3nI7T0MmSw1F33CfRewIBBHX8q9YMd 5wpZEPDq31ObiAg18wnSdalRUXPQ/P8gvGeb2Vj X-Received: by 2002:a17:907:9487:b0:c25:cb7a:12d6 with SMTP id a640c23a62f3a-c2ac528c69amr987383166b.14.1790626125962; Mon, 28 Sep 2026 13:08:45 -0700 (PDT) Received: from buildhost.darklands.se ([2001:9b1:ff:d701:51eb:176f:63d9:53f8]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2ae76abc3asm509778166b.37.2026.09.28.13.08.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Sep 2026 13:08:45 -0700 (PDT) From: Magnus Lindholm To: davem@davemloft.net, andreas@gaisler.com Cc: linmag7@gmail.com, sam@ravnborg.org, sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 2/3] sparc32: derive phys_base from the PAGE_OFFSET mapping Date: Mon, 28 Sep 2026 22:06:23 +0200 Message-ID: <9c8c84ffde99dbf747922ef93c1a73438c846e08.1790548064.git.linmag7@gmail.com> X-Mailer: git-send-email 2.53.0 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" setup_arch() computes phys_base as the base of the lowest sp_banks[] entry, that is, where RAM starts, and assumes the kernel image was loaded there. That holds for the traditional boot path, where SILO places the image at physical 0x4000 and PAGE_OFFSET is mapped to physical 0. It stops holding once the image no longer fits there. SILO loads a kernel between physical 0x4000 and its own text at 0x280000, a window of 2605056 bytes; a current sparc32 kernel is roughly twice that. The loader must then place the image elsewhere in physical memory and map PAGE_OFFSET to it, at which point phys_base describes where RAM begins rather than what PAGE_OFFSET maps to, and the two disagree. phys_base is the offset __pa() and __va() are defined in terms of, so once it is wrong every early translation is wrong by the difference, including the physical addresses written into page table descriptors. The tablewalker then follows pointers into pages that hold nothing while the same tables read back correctly through the nocache view. The failure surfaces as a hang right after the context table pointer is installed and the TLB flushed, with nothing on the console to explain it, since the PROM mappings the early console depends on have become just as unreachable. Ask the MMU what PAGE_OFFSET actually translates to and adopt that. __get_phys() already implements this probe for sun4m and sun4d and returns zero elsewhere. Restrict the probe and diagnostic to these supported platforms so that LEON does not report a bogus kernel address. No new low level MMU access is introduced. Memory below the kernel cannot be reached through the linear map, which runs upward from PAGE_OFFSET, so drop the banks that fall below it rather than leave entries that __va() would translate to below PAGE_OFFSET. With this a 6MB kernel loaded at physical 0x03000000 boots on sun4m: the context table lands at its true physical address, srmmu_inherit_prom_mappings() preserves the PROM console mappings, and srmmu.c needs no change at all, since map_kernel() already handles a non-zero phys_base via do_large_mapping(). The cost is the RAM below the load address the loader chose. SILO's memory_find() picks 48MB on machines with 64MB or more. Reviewed-by: Sam Ravnborg Signed-off-by: Magnus Lindholm Message-ID: <20260928002035.1-3-linmag7@gmail.com> --- arch/sparc/kernel/setup_32.c | 40 ++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/arch/sparc/kernel/setup_32.c b/arch/sparc/kernel/setup_32.c index 1b0db16cd37b..6d7d6fb5c49d 100644 --- a/arch/sparc/kernel/setup_32.c +++ b/arch/sparc/kernel/setup_32.c @@ -254,6 +254,30 @@ static __init void leon_patch(void) =20 struct tt_entry *sparc_ttable; =20 +/* Drop RAM below the kernel; the linear map runs upward from phys_base + * and cannot reach it. + */ +static void __init trim_sp_banks_below(unsigned long base) +{ + int i, j =3D 0; + + for (i =3D 0; sp_banks[i].num_bytes !=3D 0; i++) { + unsigned long start =3D sp_banks[i].base_addr; + unsigned long end =3D start + sp_banks[i].num_bytes; + + if (end <=3D base) + continue; /* wholly below - drop it */ + if (start < base) + start =3D base; /* straddles - trim the front */ + + sp_banks[j].base_addr =3D start; + sp_banks[j].num_bytes =3D end - start; + j++; + } + sp_banks[j].base_addr =3D 0; + sp_banks[j].num_bytes =3D 0; +} + /* Called from head_32.S - before we have setup anything * in the kernel. Be very careful with what you do here. */ @@ -332,6 +356,22 @@ void __init setup_arch(char **cmdline_p) if (highest_paddr < top) highest_paddr =3D top; } + + /* phys_base must describe what PAGE_OFFSET maps to, not where RAM starts= . */ + if (sparc_cpu_model =3D=3D sun4m || sparc_cpu_model =3D=3D sun4d) { + unsigned long real_base =3D __get_phys(PAGE_OFFSET); + + prom_printf("phys_base: RAM starts at 0x%lx, kernel is at 0x%lx\n", + phys_base, real_base); + + if (real_base && real_base !=3D phys_base) { + phys_base =3D real_base; + trim_sp_banks_below(phys_base); + prom_printf("phys_base: adopted 0x%lx, RAM below it dropped\n", + phys_base); + } + } + pfn_base =3D phys_base >> PAGE_SHIFT; =20 if (!root_flags) --=20 2.43.0 From nobody Mon Sep 28 22:30:44 2026 Received: from mail-ed2-f33.google.com (mail-ed2-f33.google.com [74.125.228.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C93C54052A2 for ; Mon, 28 Sep 2026 20:08:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.228.97 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790626130; cv=none; b=ggLoaE9jBQACZHco4u81cUcIuuSlD1qvJtWhcSVGUa7jnUBShijMOhX8C+qejSYLc4Vi7YEew0tvJOl3Cz9DEMKrp3k6st7spiT0RZ/K/YYBelPyuaHJWC4kBfO2ekdCa5UH8oJbyAk8DNweDiLp9zlgf0CKYjRykD3UW9krzRU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790626130; c=relaxed/simple; bh=AzdGodhxKE7DykxVHyS0xooKhsrpCAjLMp0Dm5wVvZA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gJkk/amIv34mgD5PQ3IxbMdepR/dQt8WuYM5nGbkbafL4pMgflTJii5QXlULI9eDmZ+fJI39QOpSzbrLbTKVQUy/KwnLb6NYNQ1oI/9YMGz2GIvpxivJovQtTZzhXLV3nl6F6jzTJm/kRaDpOFo20fm1uoLELNEtLRw3gwAoi6g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=RqoUdbVo; arc=none smtp.client-ip=74.125.228.97 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="RqoUdbVo" Received: by mail-ed2-f33.google.com with SMTP id 4fb4d7f45d1cf-6ac6f5c507fso2281069a12.1 for ; Mon, 28 Sep 2026 13:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790626127; x=1791230927; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=CE3tEgZ4a44KtqLZ+CTK+zzBvwh13usPnMe5fmHTEY0=; b=RqoUdbVo0WMwpRDmK1sdxvJydGhZJijtpBo/xOFGBn2FJj8VoPxhcVYHZ0H5e0QRJS z5Vv4V9czbSK52bApuVIfJhd3w5JGkE97qH9TKgptHRJQHJ09Gja+XKRCCgRcNDAfsnJ lfY7jEBY1yZtopfhlcb+aexUzPjFHn4GJ6t/TsHI5KnYvGdaZd2U/6dBc65Jd/B52ReF qcAOMOPsQLM9y76c4aVuYnTz4DA/DbOUPXjshVXGkHAVayLrRxyKYJwWU01I0K8/+KfX 2iybwoOtYE3i+jRKmqji6uUDQclchT6kN02DCGkctTAwnwe4G2Kuacsi2nzyK+lcTdfj Jm1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790626127; x=1791230927; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=CE3tEgZ4a44KtqLZ+CTK+zzBvwh13usPnMe5fmHTEY0=; b=vHeLOZtdDbp1PDEquaehbFGtklO7SSsWnEGnpmkalhbd7NwjZPHmM3dgR6sngm1V1G 1TrDct02qiFEd9bZx4Lghyd53d4l3580gTNTsYIvqA8y0Y2DlhIoxZHBWDgWxvjfHhZ1 UYPWw44vCN/rcBVzeWN5Eq3vJ+1p/eIRtfZ956UqA/RN28/cDEVct/AFjDYA+rpkU3MP Kg2rXVAlCjgW8cJTz9rKQMwF6EgIeVwJkSmohdS/I1BWAReLWvMhtB+TsFU2edZRHPY9 M6qv2qnIhJ/S5Pm4vvYIv/uiS3p22GhPxNzRWzDxd7Qqz8Ik9mA4tPgNf69HRDJgn+2n a8ew== X-Forwarded-Encrypted: i=1; AKwUvBxnxoLMATDVock7oQ7PoGM5c7U4cxp5BftHeLCYk0zcorlYwcvT2ZCkoxzrd7vSsW669HvHT7VhNj6SzLk=@vger.kernel.org X-Gm-Message-State: AFuF++mQDibf2pjBQbea5tw9omWn3iT0o4bBTfxvanFLFzLOB0HT2FmH 4tuXeh12j+xC5tgGTvg+KDqTUHRVXCS28Q/wlGqH4Of/xcJjoxZ8x76t X-Gm-Gg: AYBFou2RLXBWFQg3hl6ZNot49MmLgS+VCnos9It7XoYhlaJhw69cj3k9YCqrvUYOYiH hfPI9bFWMKB+j7C4s+ve9o3Wnal38DqZTt0RbmCtF1cA7bqE8ETjDDbytF33AxxEje1FkHsk4sx a2UelNNfZbj5rp4l8b5Nip+bVSvPUyPGkiec0aCjkKE5x51ilrC6NqOi6d6bjJpE0eI6krQ9baf nBROukLdlpZ1/jdJq8AKeoWSuBRZe8BDWJyihaWKYVSt+zDFmarNEOFuIq8MlOrWWxub+6VLf0w DQWwtVOnl+PnPvscc80KxZKfOhCJNp+y9FdaTyMAVQ3IRkrefz98/8cIf+G+G3rDfOnnqrmPtMK no9Pvo4gD37cEwNtEpR3+1i81tofp9H90jrp5+DfMpX/IPWCxtinzwRe7eGqc7YaaCABv+bNIB8 190NrFzVSCMRfJZ8gzI8w/Gj1aF5/UWN6V+nGtGP+IAZZYL9Prquj3TpmEE+D9L3QmN5K/HBfZg wAIkrtWxVa9iVzilNGUkh42nfInGAF0RIgG7LU0dVu4uqgctTKC X-Received: by 2002:a17:907:1888:b0:c29:286e:2e3e with SMTP id a640c23a62f3a-c2ac25ef36fmr1148656566b.38.1790626126915; Mon, 28 Sep 2026 13:08:46 -0700 (PDT) Received: from buildhost.darklands.se ([2001:9b1:ff:d701:51eb:176f:63d9:53f8]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2ae76abc3asm509778166b.37.2026.09.28.13.08.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Sep 2026 13:08:46 -0700 (PDT) From: Magnus Lindholm To: davem@davemloft.net, andreas@gaisler.com Cc: linmag7@gmail.com, sam@ravnborg.org, sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 3/3] sparc32: advertise relocatable kernel with HdrS 0x0300 Date: Mon, 28 Sep 2026 22:06:24 +0200 Message-ID: <2ed67cfac2dd3847de19eeba566254593a661e93.1790548064.git.linmag7@gmail.com> X-Mailer: git-send-email 2.53.0 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" HdrS version 0x0300 tells the boot loader that the kernel supports being located somewhere other than physical 0x4000, which is where SILO places the image on the traditional path. Anything older is copied back down there, and refused outright when it no longer fits. sparc32 could not make that claim before, because setup_arch() took phys_base from the lowest memory bank rather than from what PAGE_OFFSET maps to. It can now, so say so. Reviewed-by: Sam Ravnborg Signed-off-by: Magnus Lindholm Message-ID: <20260928002035.1-4-linmag7@gmail.com> --- arch/sparc/kernel/head_32.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/sparc/kernel/head_32.S b/arch/sparc/kernel/head_32.S index 8c320fa25a67..11a1746829a4 100644 --- a/arch/sparc/kernel/head_32.S +++ b/arch/sparc/kernel/head_32.S @@ -69,7 +69,7 @@ sun4e_notsup: */ .ascii "HdrS" .word LINUX_VERSION_CODE - .half 0x0203 /* HdrS version */ + .half 0x0300 /* HdrS version */ root_flags: .half 1 root_dev: --=20 2.43.0