== Introduction to the hardware == The SPARC V9 (64-bit) specification was published 1994; virtually all contemporary hardware is of that kind. (There is the LEON chip, but it is insignificant.) Manufacturers of well-known SPARC V9-compatible systems include Sun/Oracle and Fujitsu. These systems generally come equipped with a dedicated chip for remote console and diagnostics. The host image uses the “OpenBoot” firmware, which is also found on PowerPC-based machines, for example on Apple XServe G5. Qemu offers a sparc64 emulation mode, but the observation that it does not seem to properly boot, for example, the kernel from the Debian 6 ISO, leaves me without an impression about how slow its emulation would turn out to be. {demonstration of console} == Bootstrapping == The goal sought after comprises of a set of RPM packages installable through standard packaging mechanisms (rpm/zypper in openSUSE), and eventually, ISO/NET images. === crisp cross compilation === It is easy to produce a cross binutils and a stage1 gcc (“xgcc”) for --target=sparc64-linux, but the pitfalls are manifold: * you don't have /usr/include/asm-sparc to start with * cannot always run just-built executables - problematic if the executable is used to generate further source files * programs called from configure.ac (or whatever else) give output for the host rather than target - and they cannot even be blamed for it * then again, calling `uname -m` in configure.ac is almost always wrong anyway. Even the openSUSE ARM team knows the pains - and uses Qemu to get a native-looking environment instead. Granted, someone must have, at one time, when an architecture is new, did some hard cross-compiling. But once there, go native. === native, direct === Running native alone is not sufficient. SUSE's last SPARC edition was SUSE Linux 7.3, shipping Linux 2.4.21 and gcc-2.95. The offset to a contemporary gcc was so huge that, compiling a new gcc failed due to the too-old toolchain. It would have probably taken a careful iteration over all the gcc, glibc and binutils versions one by one - and this just was not worth its time. === native, indirect === A current toolchain is highly desirable, even if it means having to be unfaithful for a while. Debian has a SPARC port, as does Gentoo. Eventually I settled for Aurora Linux (then Fedora 12/13) as a stepping stone, because that was reasonably close to openSUSE. === rpmbuild === "Reasonably close" meaning that rpmbuild could already be used to produce packages with reasonable effort. The obstacles were few and minor - different package names, and a few SUSE-specific macros. - produce SUSE rpm using F13 environment - install F13 into a chroot - replace chroot's rpm rpmbuild --nodeps filesystem.spec rpm --root /suse --nodeps --force --install filesystem.rpm Rinse, repeat, somehow, until rpm/gcc/glibc in /suse are able to build themselves in that chroot. === Build Service === Afterwards, you want to get OBS running as soon as possible - the automated starting of builds is absolutely golden once all factory packages are imported, because many of them did not need any changes. Modifications for OBS to support SPARC have already been merged upstream and in openSUSE:Factory (prjconf). === targets === The commonly used RPM targets are “sparcv9” and “sparc64” (rpmbuild --target=), which control the generation of ELF32 and ELF64 binaries by means of -m32/-m64, respectively. The kernel package is always sparc64, but generally, one can freely mix these. rpm -U gcc47-4.7.2-0.sparcv9.rpm gcc47-64bit-4.7.2-0.sparcv9.rpm rpm -U gcc47-4.7.2-0.sparc64.rpm gcc47-32bit-4.7.2-0.sparc64.rpm is functionally pretty much equivalent, only differing in the default bitness setting. A typical system runs a 64-bit kernel with 32-bit packages, and the 64-bit variants are installable as an add-on, as there has been a 64-bit penalty associated with such processors - the same case for PPC. This currently poses a problem to zypper, which does not handle this “duality” and always prefers sparc64, due to the machine type obtained via utsname/`uname -m`. == Issues == === gcc === It seems to me that gcc does not know how to generate v9 code for ELF32, and rather produces something that is identified as v8plus by file. It turns unsigned long foo(unsigned long a, unsigned long b) { return (unsigned long long)a * b; } into assembly that uses 32-bit halfs of two registers, rather than simply using a single 64-bit register for the computation. === PROM limitations === The PROM reserves a region of 10 MB for net-downloaded images to boot. PPC has a similar limitation; the exact number is not known, but booting the SUSE installer is already impossible there. === Strange compile failures === (demo) === Build Service speed === Network latency is the killer, as are interpreted languages like Perl. At one point, I had every single Factory package linkpac'd, and my local obssrcserver and obsscheduler were, on cold start, busy with requesting metadata for every one of them, synchronously. == Status == Last successful build is 11.3. I am in the process of getting a 12.2 Base:build going, limited success. The T1000 has no CD-ROM (the success of external drives is unknown - mind you there is also no USB), so testing will be difficult. http://dl.inai.de/repos/ http://blackares.de/