From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) (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 B32073AB29E for ; Fri, 14 Aug 2026 11:04:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786705488; cv=none; b=Dv60xUd0TKd6O4RDJXHquhv92A42OJBk4aqeVm3bZye4II3HSY+TU9xBF09UBVBWrQEdVRYX+CZkoUXGuKxMxXtWVa4rckkBdLaX9xb1qdEMXmfyLkGEj2YFO2Wf/Dh+5YjV2d+RRTSr3RGRWgYm0aKbjw0ZxSp4regSp1GvBq0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786705488; c=relaxed/simple; bh=HqQ0fEQGk1bZAGwWWc+vH0JEFr0l3ZEK/aZxKLaZ6ls=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=dfLkdzwBJ3rMgnYRWiUwHcGExHW5LXLbEvrY9ri91a7dsxCzwE0YAXV9Vw55ONhPW3sGLG8XU7NiW41q7iyMLUB2M4p2l8OwML5yTWRgEekBA1d6enwbqu+haDZ7cWRil4hmZGK+TEJDEoWZp9ueX28la3CtcJIa0Qr1dcDvdgo= 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=MWIiVexS; arc=none smtp.client-ip=209.85.218.52 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="MWIiVexS" Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-c1fbe461f59so139022366b.2 for ; Fri, 14 Aug 2026 04:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786705479; x=1787310279; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=AHkk9X5Auhk5oo3B+6JZ63WAKaoKtca2c/H9g4rcRdA=; b=MWIiVexSH9wpGvnAsb8BEhC8l5ROG9NkcmZD9K5GW/xsTAVoByj22IswGgXaVfBVtB ihz4JE4cxb4ugBwVvILTAH3QJkUKhcfvY+A6uhuVg3jXbqMItJzPHTwANNa5q6E2TdEe U63Zvf44vtW4I3rQEtlEl24r14qD0jH+FlLJhCgsVx1GUu+gg2LKro6kxkY5Eo5KMzpx fZG/DvzjHJv/IXZ0PGfqM0faY84c5AITgvlr62Df/FHmecqzYfs2KAtzBStDl1sGem39 M6qckm3AclT/TARVIK9mWsew8sG9Ckk+mrbBzrSz4BP35brvZWoxL/BDfXp6nwA3BEpo sIMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786705479; x=1787310279; h=content-transfer-encoding:mime-version: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=AHkk9X5Auhk5oo3B+6JZ63WAKaoKtca2c/H9g4rcRdA=; b=NH5+rSQgj1pb6/612PXxr1nBv6FfvCNMsHJpHoVZrK++HcbbuNqUM3Y5ct3Xg0ke4J d3nEH5Eoll/O4CPFsdA8Q5JV3PU1q5l2e0pVINmSemYYCz2VEpdZEgiSytZvrxdf/Uku x4cT63H5HWnD2TGOwDyA3sMJOC8YPE58r3yb7PEz5EhMtg7xU3LPpJPJvGmfDy02uJGZ jQ4ouXezg1pNnKC2C+gtbQAaNzK2PotUPwU9+Vp/xNr4JFe82yiyBaOputVKKUcUABh1 WtJt0YPTykbmcpo7Cv5nJ98bybve5FqbdHV/XGVYa8luwYfpFXMYdnWSSNbS3SFjLBdb 0dYA== X-Forwarded-Encrypted: i=1; AHgh+Rpuok3D5FHS0LB4V/Uis6z+wVPQeK4TM6SZSuc4nZNnmB63K9f5T33R5r20F84rZsd1YOqWJabcXExAQMo=@vger.kernel.org X-Gm-Message-State: AOJu0YwAZ8e6I9jgsl39nSU2Ecei0WHBAwuflFAnzcH30ntDznwKzZ3W eccdelQ9aluTOco6rrCp0cfbqybcVLLzXQYmIIA1GKd5odXnAOI5F/Xy X-Gm-Gg: AR+sD12zUjIWHaktbjPzOgSgflQ9LKx8G9E2R0i67RPGpibVubhOxA028xVElGZGtnm 1T0IH/8Csq2Q6tdAQ5aDWfmy7Hvwtb889HbnZekxj4BS2NFi6Cl3R5u45bVNfzrx2M16pjXs2Rl AzU/OqMeA2Hxaj0lJd4rG4inCg2sKG97i72Jtz7AL9n6C31TOkNPjrGIvlCNE77Zv+j4am7U0yJ fL01vXaMiIurOj3m8EJHZG5ScMMW+yhHOy90ES9iGRbDR17N98yL9lP1NO3g8K3rnVIyhX3z3NZ 8bxMk1KqD04/QJ/oWQZqDbc9ZjJwNm/OmzhBn39k5AlIqkY5Cx9W02j8pelk53cK+fu+hvYKE/T 5PC0JFHwM14EV0A2GZS7DtGfOmvErsrSVLcmJ0CgJuZ1CT8U12RZlmOLfU/y2kVwcmYmPQ8DoPG Zs4H74AROTcNdF/7VXX72kmTsWRmExdwSr6M7uS8jlEQtOX+JpvUb+qeCvR7UZN9Pf20lCPNXrd TCLMdsmUdfpJxGVHf7gM464z+dckqS/B04VYe5/6g== X-Received: by 2002:a17:907:80a:b0:c20:2b23:71cc with SMTP id a640c23a62f3a-c2129b96a14mr220288366b.10.1786705479319; Fri, 14 Aug 2026 04:04:39 -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.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Aug 2026 04:04:38 -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 0/3] sparc32: allow a kernel loaded away from the start of RAM Date: Fri, 14 Aug 2026 12:52:31 +0200 Message-ID: <20260814105723.3454511-1-linmag7@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Many years ago I ran Linux on my SPARCstation hardware and tried to keep up with new releases, but somewhere around 3.x I hit a wall, sooner for SMP builds since they are larger. As the kernel grew it simply became too big for SILO to load. On this machine the last one that fit was 2.6.32, at 2598956 bytes against a 2605056 byte window: six kilobytes to spare. 3.12 was 184KB over. Fixing it turned out to need more than SILO changes, the kernel side needed work too, and I never got around to giving it serious thought. I recently dusted off my old SPARCs and picked the journey back up. A current sparc32 kernel no longer fits in the window SILO loads into: 0x4000 up to SILO's own text at 0x280000, about 2.5MB. Loading it higher instead exposes two places that assume the kernel sits at the start of RAM. Patch 1 is an independent pre-existing bug. viking_flush_page() and viking_mxcc_flush_page() compute a physical address as vaddr - PAGE_OFFSET, which is __pa() without phys_base. It is wrong regardless of the rest of this series; it simply cannot be observed while phys_base is zero. When it is not, iommu_flush_iotlb() flushes the wrong page, the IOMMU walks stale IOPTEs and every DMA transfer fails. It comes first so that no commit in the series leaves Viking DMA broken. Patch 2 makes setup_arch() discover a non-zero phys_base. It takes it from the lowest sp_banks[] entry today, and phys_base is the offset __pa() and __va() are defined in terms of, so once the kernel is loaded elsewhere every early translation is wrong by the difference, including the physical addresses written into page table descriptors. The tablewalker then follows pointers into pages holding nothing, while the same tables read back correctly through the nocache view, and the machine stops right after the context table pointer is installed with no console left to say why. The probe is the architecture's existing __get_phys(), which already implements it for sun4m and sun4d and returns zero elsewhere. Patch 3 sets HdrS to 0x0300, the protocol level that tells a boot loader the kernel supports being located somewhere other than physical 0x4000. No change in behaviour when phys_base is zero. Tested on a SPARCstation 20 booting from SCSI to a full userspace, with and without an initramfs, using a SILO carrying the matching loader changes. Tested with both CPU module types this machine accepts, single and dual: SuperSPARC-II, TI Viking/MXCC the path patch 1 corrects HyperSPARC RT625, ROSS SRMMU the only variant whose DVMA mappings are page coloured With two SuperSPARC modules fitted the flushes patch 1 corrects are reached through cross calls; 400MB of concurrent raw block reads on both CPUs completed with no DMA errors, where a single transfer failed immediately without the patch. HyperSPARC, which takes a different flush path entirely, boots and runs DMA with no errors and no change in disk throughput. Also boot tested under qemu-system-sparc -M SS-5, and build tested for LEON and plain sparc32_defconfig. Each commit builds on its own. Emulation cannot exercise patch 1: microSPARC-II takes a different cache flush path, and qemu models no write-back cache, so a missed flush has no consequence there. The cost is the RAM below the load address, which the loader chooses. Magnus Lindholm (3): sparc32: honour phys_base in the viking cache flush routines sparc32: derive phys_base from the PAGE_OFFSET mapping sparc32: advertise relocatable kernel with HdrS 0x0300 arch/sparc/kernel/head_32.S | 2 +- arch/sparc/kernel/setup_32.c | 40 ++++++++++++++++++++++++++++++++++++ arch/sparc/mm/viking.S | 6 ++++++ 3 files changed, 47 insertions(+), 1 deletion(-) -- 2.43.0