[Galaxy S I9000 Android Development] sztupy:
Internal workings.

In this post I'll try to describe how this works, and how it might be useful for other people.

The Kernel uses both the pre-init trick and the bootlogos trick to load up, and do it's stuff. In the pre-init phase it does the following:

initializes the devices

checks the actual state of the partitions, and decides which lagfix scheme is active

checks the config (resides in /system/etc/lagfix.conf), and if they differ runs the converter application

if they don't differ then it starts to mount the devices, and let's init run.

if during the mounting a fatal error occurs, it prints the log, waits for a couple of seconds and reboots the device.

It does the filesystem checks by mounting and checking whether mounting succeded or not. To defend against samsung's init's reformatting, it simply removes the fat.format command.

In the post-init phase it removes some files (mainly the symlinks to busybox, so they won't interfere with the busybox installed on the system). It also reinstalls fat.format, because it might be needed later.

The lagfixer is built inside clockworkmod, which has the following advantages:

Can use nandroid backup

Can use the framebuffer to show the progress (this makes it much easier to debug problems)

Besides the lagfixer there is also a "graphsh" application, which will run a specified command and prints its output to the framebuffer (the reasons for this are the same: it's much easier to debug this way than to check a log file copied to the sdcard). If a fatal error occurs this command is run so the end-user can see some logs. (all of this is still pre-init). The only problem with using the framebuffer is that core android won't boot up properly if the framebuffer was initialized beforehand (it switches to QVGA with overlapped screens... it's actually quite fun to try using android that way). That's why I always reboot after using either 'graphsh' or 'lagfixer', except for recovery modes, because CWM is using the same framebuffer anyway.

The initramfs is "ro.debuggable=1" so if anything happens one can connect to the phone in adb root mode, to check for errors. Adb is enabled by default in both CWM and base android mode. I don't know the drawbacks of using debuggable=1.

CWM was modified in order to be able to handle the various lagfix schemes. If it tries to mount, unmount or format /data,/dbdata or /cache, it asks for the lagfixer to do the actual mount, unmount or format. Therefore if one saves or restores a backup it will always see and use the actual files, and not the loop device file.

There were some other minor modifications, like binding the home button too to the enter key, using /mnt/sdcard instead of /sdcard, and the ability to back up the efs partition too. (/efs won't be restored however).

There is also a small modification in how the updates work. If there is an update, the init will always run samsung's 2e recovery, if not it will use CWM (you can use CWM's menu to run an update using CWM if desired). This is to maximize compatibility with updates.

About the compiled files:

I had a hard time getting the binaries to work, even when compiling in static mode. All of the binaries are either compiled by me using bionic (AOSP), or used from other sources (but they seem to be using bionic too). The main advantage is that the recovery binary is actually only around 700k, but has a working busybox implementation, a working recovery and some other small stuff. The main problem is with the other binaries (mainly with e2fsprogs). If I could cut from the size the whole initramfs might fit into an official kernel, so it could be used by anyone.