There are several steps involved to provide a new platform in a distribution, and the first one isn’t the kernel:
You need to be able to build programs for the platform, which means you need a compiler (and an assembler); for systems using GCC, that means you need to have Binutils and GCC available for the platform.
Once you have a compiler, you need a C library; only then will you have everything needed to build regular C programs.
With all that, you can start cross-compiling programs for your new platform; this is how platform initialisation is usually done — you won’t have a working environment on the new platform initially, you need to build it on another system.
As soon as you have a C compiler, before even the C library, you can start working on the kernel; most of the kernel is platform agnostic, but you’ll need to add a new
arch sub-directory and implement everything needed for the new platform (system initialisation, memory management, the system call interface, etc.). The Linux kernel’s build infrastructure has great support for cross-compiling, which is helpful even after architecture bring-up — embedded systems in particular benefit from being able to build their kernels on much faster systems.
The last part in platform bring-up is booting — you’ll need a boot loader of some kind, the details of which are likely to be platform-specific.
At this point you should be able to build the core of a distribution, at least enough to get a build environment running on the new platform, which will allow you to start building programs natively on the new platform. (Cross-compiling doesn’t work for everything.)
In a distribution context, once a build environment can be run on the new platform, you’d typically make it available to the general build infrastructure used by the distribution, and start building the distribution’s packages. You can see this in action on Debian Ports and the buildd stats — look in particular at the package availability graphs:
The vertical lines indicate when a new architecture is brought up; there’s a quick ramp-up with all the packages that build “easily” for the new architecture, then varying progress towards 100%. (An architecture can never reach 100% because some packages are architecture-specific.)
The graph for unofficial architectures is also interesting:
Up-and-coming architectures like
riscv64 can easily be identified, as can dying architectures like