From nobody Tue Sep 29 00:32:56 2026 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) (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 EF32B371D13 for ; Fri, 14 Aug 2026 11:04:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786705488; cv=none; b=Kh3lmvG/X6inzlZ1uiQ5oN7Vu2IdwrPlU3aPmbb9hZXLJcDpu5in5D5OnCW5kfkNUU14m4NQGK8BGgwd2xiOyrf1DgMpcETcjg1wgijxMluPm1kBiw93gnCBKuuUjMSDebhg7RXT2rlCu+RnilgZ6sDMuZRrTjAjaxzlzgFUDoM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786705488; c=relaxed/simple; bh=7ZS9XfQBg3/J/2JclDC1KmYn/5ZetW387cKqolJQXzc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TSUxV8CsRLxI/15Z6dzFqTYunIi8ApBuRzVc+JDuUzJynb4Zkfdq/MzKSEh2tKZ2ugFbwtBtbtDyAp4lzgHmqEHwVl43o9i+WVcKqLzm0aNurkZJGrmUzDiTocBVq94m/2epfub1gRYpwG5j0K+8ojZvJb3YY0Rt8RWt5EddQtw= 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=jX+oQS5q; arc=none smtp.client-ip=209.85.218.49 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="jX+oQS5q" Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-c15d3cd51b2so112365666b.3 for ; Fri, 14 Aug 2026 04:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786705481; x=1787310281; 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=xFVxe3t9mWeVpbsGrII+FmHHHZF4AA0TdlMjQEfc1jM=; b=jX+oQS5qIzGP/LxnmwCzXfcxruK7ZApgHgCCvA5h7eAu7LZ3+8hNhrgs2Fh7rViuf1 o3u2OABhIVt6CwE+eowQJiNSO3StQmPGGFQ4O4+YckwPLDbxxOYA2xRAVqspBC58dC3N HoZcE5Z06v8G2oxpg+OyjMsaQu67GXWjKApLVtESRrUEYXgRWvfru0KjlDeIProGJmTb eZn1+hX8Il2m5CJt1knL56w+E+XPfR6yVTgdbNfMuLfW2O8vclzs6PH+UzU2kLJ4IKh3 VQWwWgQq+HSi36Wpfnf3NwgZltkYGH5nqo6LZYDbI8sIllU+cZaCRZbN9LQ9HaW+nFkE xvIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786705481; x=1787310281; 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=xFVxe3t9mWeVpbsGrII+FmHHHZF4AA0TdlMjQEfc1jM=; b=YUeNTZ+lRb7WWaGgHwcKVKpe2NnLfDIxMtDVJdHalvmsnc8mGAQm69X3dS+bkmgNUZ RqTvSMhLAtvmqSMhp7I/Pg4cAmsBN1vQoExnufesfyaZgHlmCmGO9NUKk2eNnbjaF28H JBq2S8/HuTgt8ia7d6Zj65Zt5crJ+qyL4VBbkTLBf0szibYi/5FuZTsSB7MRqojiIbp0 OIL6Cmot4Xn8u5dc9YRHFdVGJUwksTPxbsSQRdF8KG7UQEqs7nnMMZUSRD28nvCp+GF2 6npnRltLJpmX/5tcNHgGblaluvpeT544RLFe9IsmVMjBrkWkkVr3vLo4/5CDzvEGsg7+ Fk0Q== X-Forwarded-Encrypted: i=1; AHgh+Rr9NAXNkW3DLmKV46FP4wfSG5LnVDfGlA4KaU/QDlf06RD1lFhK27moIDvvhnrSF6Xi/jYPN6bCUuZOlWA=@vger.kernel.org X-Gm-Message-State: AOJu0YwPSkESoBYtpFz6LMJenkPM7aLh0+4X3LKr2f4IP3Nv5+CSrpHA p1HzPcgmdCVJyPIrnzuv4EdtCXb50ZJ/cgtTr7MGgUKvOOIv8UG8lK/p X-Gm-Gg: AR+sD11YSYFSVghTcxPo8XMPaxzoeatfBQ4C1hOVcvNCcH18kCg5OPDC5CTDPuOErDL 1KhiV/wBWUjCQnFmlsbA2s8zcUVP4+/vw3kUbBiecCCVhytBOhYVTCrVg5rm4j2UHxexNw5yAVd BSOlFwJ1DsoBeSNq9mZEsdeI/zaSAFE2A/ucE8k0G8EWutUAcNnwKLqDSkSAJ1donzdE4Fo/6ac pipkHkj5ESDaQ4Z9UqHlZjZArSIKL6LCGlcpAOX9cPas0nyiq7rtWDJFHL7PuYRtyPxg07PGITW 3jLbsba1dwUUxJ1qGkPgfI4pcW44c1b9Q4/0b9+YjPTrcSDvvh+JtbigvOoxaCq8NlfP1wBCetq GRNbzT0MR7pGKMmztoLfijH+XRsk2BCvAei3ykMSAvQuNOpRgZ651fj0BPHd+YMTgU+DupfE0Ou 8J+xAx3msXuiMaWIjMlJm5G36FEPgh+DG3hdje552/chZqplEnS82q2zxAsg4Qry4viwrsJAzMX fgstqEXa3C1iuDMMYitY6/LhuNgmVgs3k6TWBtEB4A= X-Received: by 2002:a17:907:94cc:b0:c20:7897:bc69 with SMTP id a640c23a62f3a-c212a8d86a9mr208542866b.30.1786705480333; Fri, 14 Aug 2026 04:04:40 -0700 (PDT) Received: from buildhost.darklands.se ([2001:9b1:ff:d701:51eb:176f:63d9:53f8]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c21233a12e6sm92028366b.12.2026.08.14.04.04.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Aug 2026 04:04:39 -0700 (PDT) From: Magnus Lindholm To: davem@davemloft.net, andreas@gaisler.com Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, Magnus Lindholm Subject: [PATCH 1/3] sparc32: honour phys_base in the viking cache flush routines Date: Fri, 14 Aug 2026 12:52:32 +0200 Message-ID: <20260814105723.3454511-2-linmag7@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260814105723.3454511-1-linmag7@gmail.com> References: <20260814105723.3454511-1-linmag7@gmail.com> 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. Signed-off-by: Magnus Lindholm Reviewed-by: Sam Ravnborg --- 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 Tue Sep 29 00:32:56 2026 Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) (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 EF60045C710 for ; Fri, 14 Aug 2026 11:04:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.48 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786705488; cv=none; b=ni+YpxrNNXNxL5H8W8ptJUcmndqVsr/mvE1SCELDWe/fHj+4yZrc4C054oK7Otc3MnPCh/6IH7fySbnEVQtz7PiQoXRfbA8PkIvlRhpF+u71yNcOrtQnlKq1A9bLFGwwhkDY9wIBZeF3BWMOW7K/b2/dtsa/ehMWCzOL1lCePWI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786705488; c=relaxed/simple; bh=n0+oMFlCicrxC3zHuZmFe9MeT+CoF1ugOOoTEU4PhmQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ecfbvgg2VoWIvMbz8qAOpl0zQWI389opYAk8ZRfkEukJ0KA7GAJHMuKUrANp86chNns4B8KEgdFZyzD0QOaInhXbM/5vhu+sS/84ucvLZpVNUTK5CvrLgJXsUQExhQlKJX96S+yoe0XuXN8Myuj3z4pjaUZ2/tOq8p00uec/O1Y= 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=Bhl5goGk; arc=none smtp.client-ip=209.85.218.48 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="Bhl5goGk" Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-c20fb91ed0fso151223066b.3 for ; Fri, 14 Aug 2026 04:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786705482; x=1787310282; 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=+C3yDrnyWElju51nv3m1vHWDYdz4gkHACkImbfPvTRU=; b=Bhl5goGkYgG8pNAiiGjnBJ7cRjPUV+in2o42jSbpc7VDool6JItgh7+4WKqTdoWeJt EZq/VbNEB92qzmEWtjL8LsBDTdbnVxGwcqAam+H8fD61rYRN+zRWQppWbQ5sWMj85yy5 PlLJhkFaf4z7gjBPsl7LwK5v5sUjP5oa1leKs6J3E/OH5FQlhdXYX66Qs3p3oyznIwW9 5A7VtfJT4G3zSZk21mpxkX9dlEpHCWmmQWoMIRC4ugsTqgC5QqD3N68HNFEE99MwKE/j LhJ8CyyMyjpOf70PwjfRQDOXrgVUUa4VlVhvyd/7mBDML+Z4NszxFWWc4QkgMqC785nY zpjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786705482; x=1787310282; 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=+C3yDrnyWElju51nv3m1vHWDYdz4gkHACkImbfPvTRU=; b=kiwJXtmMMXLY5qB44ycbq2YDXK5FZE3ZTk//f3oh4ZLhpLk7ZBu/WayMxtKuSiGYQX 9Wb/GggBzO6sd6FIWB0zuxIrwfVa16jvN/xVExWjS808ojH+T3fKuyKOxikOeOLr/bBJ M5nvUnuJNgBx1gVGvBtOh5USq4iECTU4WiohG8zU/UO3iALyqWnLqsomV2KVJMD6y5Vn umPPVuhCSHDOiEy5re3rW6sXDMrNGka9kutGehrUi82TMp1OQAjsjy55XFbi2H1r3Wmg s9cMl0gFfq3+Hd3KFjX4xapE65MP/ZmKPni8SHENKKTf8VQRgsp1lhUy7o3rBhxcuEiT aMzw== X-Forwarded-Encrypted: i=1; AHgh+Rpsiwk5SPnWEJf+mzYaLwFfBzWAfvI1ZSAefd6G6QS/BNsHK7LfiJUJsrPlDnYU5UIHXxWBSj8xdbMIBYI=@vger.kernel.org X-Gm-Message-State: AOJu0YzvUmpRoDwAg+qmSjNXXQYcypKkyEV1Cd1o5zJTj3RdnF6k/4bj DpXwRz0AQzCC6dMnRInrFMOEfwGF3NgCFawlxWo39KVWfjJyuyTjwt6f X-Gm-Gg: AR+sD12SxE84cZB4o9coSSd9CiGYaj7HWR/98jnT8cClhg3MEm0MmyUiz8bj5a54SnP pPPgNyj5P6uPeuy9CjnvwNbE4xcjmUS0WpviYJvmEx3zv5erQREH/z1JJLRhW1Qkg6t/WKparD2 lI9IIhkHZbAbPigs4FMHw7RL7SN4fV/wud/QD5uR2bZVRQoJn7PkLlnYkdr0f19tIfrlwqqz+ri BC6RsMuJYWYJedxm+hKk2pP7KkyWxw9Z1p8Hh4axlLVnLnB4i1SKF7P59wKHDUmY427lHBnwtLZ kKTDwJeah4fQqzzGzunL6pWm2jUrO114CoBtUDpqHQsnHRDOnaX1YczcL81od1VlJDHew7pTlzN OgGdgVRa7AlOc8sVkJyN6OeKWNKQz+MdAUrN638hZc99JgRZaidMlOH6o0Sgrn9hnDUoXtvw/M0 H3qdA5R3qK3BAjbBR7imayHEBqMGOkUwSDw/CaO5T2v4l1FXfFT4sbcpG/KeDXujECg7kimfbSe qILWZqKG3EeDJoe9nZZ7U6E3s3IU427aPRKlP9ZEw== X-Received: by 2002:a17:907:3f09:b0:c15:e118:9b99 with SMTP id a640c23a62f3a-c212aa4d8d5mr190069166b.23.1786705481429; Fri, 14 Aug 2026 04:04:41 -0700 (PDT) Received: from buildhost.darklands.se ([2001:9b1:ff:d701:51eb:176f:63d9:53f8]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c21233a12e6sm92028366b.12.2026.08.14.04.04.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Aug 2026 04:04:40 -0700 (PDT) From: Magnus Lindholm To: davem@davemloft.net, andreas@gaisler.com Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, Magnus Lindholm Subject: [PATCH 2/3] sparc32: derive phys_base from the PAGE_OFFSET mapping Date: Fri, 14 Aug 2026 12:52:33 +0200 Message-ID: <20260814105723.3454511-3-linmag7@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260814105723.3454511-1-linmag7@gmail.com> References: <20260814105723.3454511-1-linmag7@gmail.com> 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, so no new low level MMU access is introduced and machines without an SRMMU are unaffected. 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. Signed-off-by: Magnus Lindholm --- 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..795714959da6 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= . */ + { + unsigned long real_base =3D __get_phys(PAGE_OFFSET); + + if (real_base && real_base !=3D phys_base) { + prom_printf("phys_base: RAM starts 0x%x but kernel is at 0x%x\n", + (unsigned int)phys_base, + (unsigned int)real_base); + phys_base =3D real_base; + trim_sp_banks_below(phys_base); + prom_printf("phys_base: adopted 0x%x, RAM below it dropped\n", + (unsigned int)phys_base); + } + } + pfn_base =3D phys_base >> PAGE_SHIFT; =20 if (!root_flags) --=20 2.43.0 From nobody Tue Sep 29 00:32:56 2026 Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) (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 75AD032D7C7 for ; Fri, 14 Aug 2026 11:04:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786705489; cv=none; b=KumS+m9NaMuzuJRuIkab9TIWdZNNeA9Gvrh+V+B/bEO1cKziNVDceisn139ZVnK1rM9A5RsSLjyXW6xlhf38EnO2L6eQjMrCkp1ZpTQ8ou3zgbbzlPi7T2YTFjKPCvDybPoYjEEtHkgsx3wwM0XG0b+QGJ5lT+/JfpYsO3E5Adw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786705489; c=relaxed/simple; bh=ZcvHgI3U1UUIH3Y/QsAcb3zSzGUk/Kqj3EmUTTtZ0WQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IuAs/AHUm2FtJPoX3m7P/YwbE9Kc9DAmenhSXrm0IyRmhSPsj4qWxaVMakoOuP7OH5+GqxaUazf5ICy0dJkyKtTbL/2sykFSBC8XCvhNyg2cKfbZmKoMw989O2yjTDEXJsuGCEfok1po38PbUgXgAohK+dJvVNEd1psazOYjnl0= 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=qesa6303; arc=none smtp.client-ip=209.85.218.51 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="qesa6303" Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-c1c50c1e29bso128838566b.3 for ; Fri, 14 Aug 2026 04:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786705482; x=1787310282; 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=48xmVgdSxn1ziJVhznRmfvGtQ8ErzBcg/MTqWjfxPSc=; b=qesa6303n6Vk0DtRBjSG1MbH6FGmpFpWAATulNaY0nhZFTl06CQwRlgOi4pZ0P49f0 euBqSfpO8l5kkRg0lCZnUA323nI7XveJLMQkXgCCvSw2Q0d1iJACVOlcgZoIKOK/+b82 ourMgCqDbfa3iz/KC+n2HhcUoMlvLVwSFY22MocKf9vkBOR673l7EQg7W32ZVZ3na9cw 3YE7/HYcI9OkwCWmg2aaVmUA2r533tIE5y+aQLQ14/I5BC61Fe0fYWaKPh0XWbE9SX/8 f8o0EWjkbrS6N0VwrzGsaJ4io4KM7ZjpE8pIpmq8zBjScVlRUOe8L1lpuYV5yi9fMX2S BEfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786705482; x=1787310282; 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=48xmVgdSxn1ziJVhznRmfvGtQ8ErzBcg/MTqWjfxPSc=; b=BVsAFpQjEd6kMibA/ZlaW34cMiJSsyGS63zjsnRonITKL62UzK9Yigb872wfYZ/tbX cct+4Zx6rlLktiG+4Mjm7E/iQRM+JU1SHWeTDtr2bdlUCutTyi1lVQHRLNtVnNe5YYSm e7GKJy8ztQpRFhGwhr47LFwsjYlZT6O2o3UyJJoyfPT9PMrm2Lg3mBrVvPOvj9dgaY9F +E2whKdJlrYz9Qm0CCyHGK8o4PXavOjzWiqzYLRmmQDAtM71qPvtMMDgc11CyXNDGtHo PRIGxMxE/wzFwI8gD9XEhaAcBVfafYGb8vJyiRfvvOl0cn6qUDM5QLDmtVah05SNxIXU MMXA== X-Forwarded-Encrypted: i=1; AHgh+Rp2E/hDZp6IqaxqO0+vfSbW+Yp4Wmyhhn0bFuWj+LoHDSsWHd1adTmRyZphe5Op0q0NYwkbZCgrdNT9y1s=@vger.kernel.org X-Gm-Message-State: AOJu0Yzpvzh6mX+p7s7lMjOKuwTQoRVitO0+HPxik4qOaS87tMOgJ/7c Q4bJhgaOfGiz6d2CdTeT2FkVA+MX+mKrJahrYJcPrH+jPtrzfFZ6a3ECF25GnA== X-Gm-Gg: AR+sD11iD9mYSHafk/VmsbjBpE9dIC94H9e/RcsOt9t2Z6cAAOXh5KIrwDu2hTjogan u7FKPl2aYoBX3peY8X4/oOFDkoLOJH3HffiZGSzLU0RAkpRKzUtEQGs+EysgW+tphMLMQnQP2x5 /tJ00gDPTd2hI+kaHMlJP936bEg32/fWFA00U1UcODtooZBPelht+CdtawbGigR/wZt+atpCYNS Cl20jz+tBvb12BKoxO37h52zh9ag2g3OeaiF25DSaoJSVfhUPHUW7wBuIFspH8ApTRtb9XwsSnH 9GvY1aAB1wxQ9oeYIwu8CJ46l3OofqH2q9nKb27jBqizUDnSFLVUjU6oa0AgsxCf4nhhzOwMFNq 66sbv8iD6ogC9ZUv1JRaWrP0q0a40sNaAjKPeiZSpJYG3EqfOsjViJa0kPJfLNyziVNIVagmTHC O+dV3E8HJ6oanbR5AKJzZprjkt+OzSMA3FeLoU5E5SjhHCjeyXfwMxb9BWcD3M7h7MhBMOVJV0K GVTkxPK2e7u4xQvpuXVKBDfJbZ11oo= X-Received: by 2002:a05:6938:a094:10b0:c16:67d8:7a0f with SMTP id a640c23a62f3a-c212a3425e0mr145770866b.28.1786705482320; Fri, 14 Aug 2026 04:04:42 -0700 (PDT) Received: from buildhost.darklands.se ([2001:9b1:ff:d701:51eb:176f:63d9:53f8]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c21233a12e6sm92028366b.12.2026.08.14.04.04.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Aug 2026 04:04:41 -0700 (PDT) From: Magnus Lindholm To: davem@davemloft.net, andreas@gaisler.com Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, Magnus Lindholm Subject: [PATCH 3/3] sparc32: advertise relocatable kernel with HdrS 0x0300 Date: Fri, 14 Aug 2026 12:52:34 +0200 Message-ID: <20260814105723.3454511-4-linmag7@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260814105723.3454511-1-linmag7@gmail.com> References: <20260814105723.3454511-1-linmag7@gmail.com> 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. Signed-off-by: Magnus Lindholm Reviewed-by: Sam Ravnborg --- 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