(Much of this section written by Jesper Skov)
Since the release kernels found at the various Linux/m68k sites are compiled for the average user, they contain drivers for just about every piece of hardware supported by Linux. They will also be compiled so they can be run on all the processors in the Motorola 68000 family.
This scheme enables everybody to boot Linux, but it also reduces the performance of Linux: drivers for hardware you don't have or use take up (non-swappable) memory, and in case of processor specific programming, it is required to check which set of instructions to run.
Therefore, if you are a bit adventurous and have time to spare, you should recompile a kernel for your machine configuration. Especially if you are not a kernel hacker (i.e., you don't care about all those 2-3 line patches :) and use the same kernel for several days/weeks, the time will be well-spent. (Of course, if you are a kernel hacker, the time will be well-spent as well. :)
Recompiling your own kernel will make it possible to configure it to your exact machine configuration, thus giving the best performance possible.
The Linux/m68k sources are available by FTP from sunsite.auc.dk in "/projects/680x0/vx.x", x.x denoting the latest version numbers.
The sources are also mirrored at the sites listed in the section called FTP sites in Chapter 11.
DO NOT try to use standard Linux kernel source trees (from e.g. ftp.kernel.org) to compile Linux/m68k. These trees are often out-of-date and may include serious bugs due to changes being made on some architectures not being propagated to Linux/m68k. Stick to Jes's source trees (or Jesper's for Linux/APUS) unless you really know what you are doing.
You will need at least gcc version 2.7.2 (preferably 2.7.2.1 or later) to compile the kernel.
Recompiling the kernel for the MC68060 processor requires binutils 2.7.0.3 or later, fixing a linking problem with the ifpsp (integer/floating point support) files.
Linux 2.1.x and later require binutils 2.7.0.3 (or later) with the CHIP fix. This makes it possible to specify which processor (chip) the instructions should be assembled for. Thus it is now possible to write mnemonics instead of opcodes for the bigger processors, easing the reading of the code and removing the problem of wrong mnemonic/opcode translations.
GCC can be found at any of the Linux/m68k FTP sites (see the section called FTP sites in Chapter 11). The required version of the binutils package can be found at ftp://sunsite.auc.dk/projects/680x0/bin/.
There are three important stages: configuring the kernel; generating the dependencies and compilation of the main kernel (vmlinux); and building modules. You can choose to either use modules (non-essential modules can be demand-loaded by the kernel) or not use modules (which means all of your drivers will be built into the kernel). Using modules makes your kernel and drivers slightly bigger, but if you don't use several devices most of the time (like your printer port, CD-ROM, and various filesystem formats) you will save system memory when they are not in use (as none of the kernel itself can be swapped to disk).
Note that this is a generic set of instructions; Debian comes with a package called "kernel-package" that automates the compilation and installation steps (and integrates them into the Debian package system; a side benefit of installing kernel-package is that installing it makes you install all of the other packages needed to compile a kernel). No doubt Red Hat has a similar facility. In any event, the general principles discussed here apply no matter how you actually compile the kernel.
cd to your kernel source directory (e.g. cd /usr/src/linux)
Type make config. (If you have the ncurses headers installed on your system, you may want to use make menuconfig instead, because it is more forgiving of mistakes, though it is slower. You can also use make xconfig if you have Tcl/Tk and want to configure under X, or make oldconfig if you have already configured a kernel and just want to be prompted for new options.)
Answer the questions you are asked (or answer all of the questions under each menu, if you're using menuconfig). Most questions will be Yes or No questions; if you choose to use modules, you can also answer M to many of the questions to build a module.
If you do use modules, you cannot modularize your boot device (i.e. your IDE or SCSI controller) or your root partition's filesystem format (usually ext2); I recommend against modularizing the ramdisk support (in case you ever need to boot from a ramdisk for some reason). I also recommend that you answer yes to the questions about kerneld or kmod support (and be sure to get a copy of modutils and install it on your system).
Eventually it will stop asking questions and you will get your command prompt back. (menuconfig has a "Save and Exit" option that will get you out when you're done answering questions.)
This part is easy. Type make clean; make dep; make (all on one line, with semicolons between each command). Then go away while your computer heats your house; the compilation speed depends on (a) how much RAM you have, (b) how fast your CPU is and (c) how fast your hard drive and its controller are. Slow computers (like 68020s) can take over a day to compile a kernel; some 68060 owners have reported compilation times measured in minutes. Some computers (with lots of RAM) will benefit from running the last make as a parallel make (using the -j switch); see the manual page for make for details. When it is done, you should have a file called vmlinux with the kernel in it.
Compiling the modules is also easy; type make modules; make modules_install and then go home and eat popcorn (you can combine this line with the compilation line above, e.g. chain the 5 makes together on one line). You should end up with a lot of files under /lib/modules/X.Y.Z (where X.Y.Z is your kernel version number).
Generally, all you should need to do is copy the vmlinux file to wherever your bootstrap expects to find it (for ataboot and amiboot, this will be on a native filesystem partition; for LILO it will probably be in / or /boot, but this can be configured differently). Make sure you keep a copy of your previous vmlinux file where you can get to it (or set up LILO so you can boot from the previous file if necessary), just in case something goes wrong.
Linux/m68k releases are built and released by Jes Degn Sørensen. "Built" means that you can write a patch against the current version or patchlevel and send it to Jes and he will integrate it into one of the next releases. Make sure you state against which version the patch was made. Please note that Jes has no way to test Atari-specific patches.
It is also considered good etiquette to send your patch to the Linux/m68k mailing list, so (a) Jes can see if other people say it works (a crude form of peer review, if you will) and (b) so everyone else on the list has a new patch to fool around with (a crude form of everyone getting their kernel-hacking fix ;).
Note: If you patch processor-specific code (e.g. 68030 vs. 68040 MMU or FPU) make sure that you document the dependencies.
Send bug reports to the author of the code or to Jes. Probably a better approach is to post it to the linux-m68k mailing list or to the appropriate newsgroup. If there are bugs that will probably stay in the code for an extended period of time let me know so I may publish them here.