Re: [PATCH 0/3] sparc32: allow a kernel loaded away from the start of RAM

Hi Magnus.

On Fri, Aug 14, 2026 at 12:52:31PM +0200, Magnus Lindholm wrote:
> 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

I thought Viking was only used by the large sun4d machine.
Good to learn something new here.

Nice to see someone having fun with these Sun machines.
I gave up and have actually tried to have the support for sun4m and
sun4d removed from the kernel.

	Sam