Eddie,
I think part of your problem may be an out of date SILO. The one from Etch can only load about 2.5MB The most recent one I think its something like 3Megs - 128k - 0x4000 bytes or something of that nature, I imagine Sam or Davem would be able to comment on that more exactly than I.
I have sparc32 images of Gentoo here that were last updated in 2014 (there is a portage/python bug that prevents them from self hosting on a real sparc32 machine but they do self host within a chroot on sparc64 without too much trouble).
http://gh0stwriter.net/gentoo/
I'm hoping to update my install CD and stage3 images to a recent kernel... basically by taking
Linux 4.8.6 running make tinyconfig (which results in an 850kb minimum kernel)
+ add all the stuff needed to run Gentoo (also enable under expert, at least futex and multiuser)
+ driver modules
+ Minimal networking
+ all sun4m graphics cards
+ tty + console on tty + sun keyboard&mouse
+ bult in esp SCSI driver
+ SCSI disk and cdrom
+ built in ext2 and iso9660 fs support
-disable all the extra unneeded featues under the block layer except for maybe the deadline scheduler instead of no-op.
which results in a 2768876 byte stripped vmlinux.
That should still be loadable by SILO newer than about 2010 or 2011 I think older versions of SILO are limited to 2605056 bytes but newer SILO adds a few hundred more Kb [1] by relocating second.b closer to the end of initialized memory. I think this should work, best case I will have ext2 for the boot partition built in, ext2 or ext4 (module loaded in uncompressed initramfs) for the root, worst case I'll run into some problem... that prevents all this from working. But my current kernel does boot in QEMU which circumvents the SILO issues as QEMU can load the kernel directly.
I would suggest getting a decent sparc64 box maybe a T5120 etc... and using that for builds in a chroot, I use my T2000 , it will work much better the cross compiling as there just aren't enough people testing cross compilation for it to be reliable (I say that not having tried Debian's toolchain as using a chroot was easier than figuring all that out IMO), the important part is that they end up being sparc v8 and you don't have to fight with toolchains producing v8+ code what won't even run on a v8 CPU except maybe for Leon4 and maybe 3 which added the atomic instructions in the v8 spec. I think building glibc was/is quite problematic with a cross toolchain.
http://gh0stwriter.net/gentoo/distfiles/linux-4.8.6.config here is my latest .config note that this is for gentoo-sources but much of it should mostly carry over to getting a kernel small enough to boot on Debian.
Also, if anyone wants to continue the work to finish making sparc32 relocatable I'd throw a few bucks at that :-)
In any case I just do this for fun when I feel motivated in my free time... it's nice to see some of the machines I have running recent code. I have a large segment of the sun4m series including some odd ones like a Sparcbook 3GX, SparcPlug and sun4d SS1000 which sadly isn't bootable at the moment. I almost snagged a Sparcbook 3TX once but missed it... and am still looking for an AG10E graphics accelerator, A HyperStation30 , and it might be nice to have anything with a 170Mhz TurboSparc in it.
...
[1] https://patchwork.ozlabs.org/patch/28639/
Chase Rayfield