[Fascinate Android Development] comradesven:
Ah! A source building question! Always nice to see people trying to figure it out for themselves. Just, don't build the source I have up now, I don't like what's happened to it. ;) I've spent the past few days redoing everything from scratch so I can say a few words on the subject while my mind's still fresh. I'll upload my new kernel tree shortly.

I can't speak to the platform (Android files) but as far as the kernel goes, if you are starting fresh, Samsung's source doesn't just build because they wanted to keep the patented secrets out of reach. You will need a toolchain, the Tiny FSR driver (drivers/tfsr), and a copy of the stock initramfs or ramdisk. So let's get into each of these, because it's fresh in my mind and people may find it helpful. I'll assume some Linux knowledge here because to explain it all would be goddamn ridiculously beyond the scope of this post.

1. You need a cross-compiling toolchain. That means that with your x86-architecture computer you're running a compiler that spits out binaries that run on a totally different architecture. (ARM EABI). There are several places you can get these but most people use CodeSourcery Lite, Linaro or straight GCC. The two former are enhanced versions of the latter. Actually the only people using straight GCC are probably only using it because it's included in AOSP or CyanogenMod's source trees, but whatever. Samsung themselves use CodeSourcery arm2009q3, which is a little outdated being GCC 4.4.1 when they're up to 4.6 by now, but GCC 4.4 seems to be more forgiving with lazily written code than 4.5 and 4.6.

There are several types of toolchains you can get. Those labeled arm-eabi include only the basics to make code run on "bare metal hardware" and will build kernels OK. If it's labeled something like arm-eabi-linux-none it includes some additional libraries to let programs written for Linux to be made as well.

You can set the architecture (ARCH=arm) and the cross compiler (CROSS_COMPILE=path/to/toolchain/directory/prefix-) in the environment, on the command line, inside the kernel Makefile, an architecture-specific Makefile, or in the kernel config file. In my new kernel tree, which I will upload shortly, they're set both in the kernel Makefile and on the command line. The build scripts invoke make ARCH=arm CROSS_COMPILE=toolchainpath/prefix and override the kernel makefile but you can just run "make" at the command line after configuring and it will eventually spit out a kernel as arch/arm/boot/zImage. However the build scripts take care of packaging it up nicely into a CWM zip and Odin-compatible tar.md5.

To change toolchain paths look inside the build scripts I wrote and in Makefile in the kernel root directory for "eabi", and go from there. Again you only really need to change the paths in the build scripts.

2. FSR is a necessary driver for the kernel to be able to see the partitions on the OneNAND internal storage of the phone. When you integrate a new driver into the kernel source tree you need to make sure of a few things. The Kconfig and Makefile in the driver's directory (drivers/tfsr/Kconfig and /drivers/tfsr/Makefile) and in the directory one level above that (drivers/Kconfig &c.) need to include the necessary changes for the Linux build system to see them. Then you need to make sure that the configuration file has the correct parameters for the new driver. Default configurations are stored in this case in arch/arm/configs.

Kernel building requires at least two steps - the configuration step and the build step. You run make [ARCH=somearchitecture CROSS_COMPILE=something] some_defconfig and autoconf looks inside arch/somearchitecture/configs/ for some_defaultconfig, looks recursively for all the files named Kconfig in the Linux source tree, generates a list of options, fills out the list, and puts a file named .config at the kernel tree root. (Appending a period before the file name makes the file hidden in Linux so use ls -a or set you file manager to show hidden files to see it.) You can change these options by running make menuconfig.

The TFSR driver needs a flash base address and some other parameters configured. tksgb_defconfig has the correct values. The build scripts invoke make ARCH=arm CROSS_COMPILE=toolchainpath/prefix- tksgb_defconfig and after that the kernel will be configured.

3. Even after you put TFSR into the kernel tree the kernel relies upon precompiled modules in the ramdisk for the regular FSR and RFS drivers. Kernel "version magic" needs to match exactly. There is an option in the defconfig to append a localversion to the kernel configuration file (.config in the kernel root) which shouldn't be set and something in the build system that automatically appends a + to the version if the git repo is not clean at build time that needs to be changed. There is a commit in my git that takes care of the latter and for the former you just have to make sure that your defconfig doesn't set that or you don't set it yourself if you're doing a make menuconfig.

The location of the initramfs/ramdisk needs to be configured correctly too. I put a Voodoo-compatible one and the stock one in build/ in my new tree.

When the Linux kernel runs with a ramdisk, it decompresses it to the device's RAM and sets that as the filesystem root. The ramdisk includes the init executable and some configuration files akin to the old DOS autoexec.bat and config.sys that set up the system environment and mount the partitions and eventually run Android, which like Windows 3.1 runs on top of the underlying Linux system.

In my new tree, as long as you have all the prerequisites, you should be able to set the toolchain path in build.sh and get a working kernel in build/out with a simple ./build.sh (or ./build_log.sh if you want to capture all the build output into a logfile).

Eventually I'll get the README written up and a better build script in place but there are a lot of other places you can look for help if you want to try your hand at building Linux for your phone.