Building AOKP for the Nexus S

Building any AOSP variant for a Nexus device is pretty straightforward, as the device tree is already included by Goole and they are well tested & supported devices. In order to build AOKP (AOSP variant with some tweaks):

The source code is here (check the README below):
https://github.com/AOKP/vendor_aokp

First of, clone the whole code from git

mkdir ~/bin
PATH=~/bin:$PATH
curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo
chmod a+x ~/bin/repo
repo init -u https://github.com/AOKP/platform_manifest.git -b jb

Then sync:

repo sync -j16

-jNN will speed up things for multicore - fast - connected build environments, BUT it may lock on Ubuntu because of its broken python impementation. To avoid this problem:

sudo sysctl -w net.ipv4.tcp_window_scaling=0
repo sync -j1

For building AOKP I prepare a handy script that set ups ccache (to speedup things) and builds for "crespo" that is Nexus S. This script might be on vendor/aokp/build.sh for instance:

export USER=alienmind
export USE_CCACHE=1
export CCACHE_DIR=/$HOME/.ccache
prebuilts/misc/linux-x86/ccache/ccache -M 40G
source build/envsetup.sh
lunch aokp_crespo-userdebug
make -j1 otapackage # bacon
#brunch $DEV

There are three build types:

Buildtype	Use
user	limited access; suited for production
userdebug	like "user" but with root access and debuggability; preferred for debugging
eng	development configuration with additional debugging tools

References:  http://source.android.com/source/building-devices.html

Android preferences

Reworking icetool preferences the proper way ...

Modding boot.img

Modding boot.img can be useful for changing kernel or init scripts on ramdisk.

The ramdisk itself contains - for instance - default.prop that can be edited to unsecure the image - that means having adb shell directly as root, or ability to use adb remount
Boot partition can be extracted with dd if=/dev/mtd/mtd2 (on Nexus S) or as generic way, from recovery using flash_dump boot boot.img

Needed steps are:

$ unpack-bootimg.pl boot.img 
kernel written to boot.img-kernel.gz
ramdisk written to boot.img-ramdisk.cpio.gz

removed old directory boot.img-ramdisk

gzip: ../boot.img-ramdisk.cpio.gz: decompression OK, trailing garbage ignored
529 blocks

extracted ramdisk contents to directory boot.img-ramdisk/

$ cd boot.img-ramdisk/
# ... do whatever edits you need ...

# Repack
$ find . | cpio -o  -H newc | gzip > ../boot.img-ramdisk-new.cpio.gz
$ cd ..
$ mkbootimg --kernel boot.img-kernel.gz --ramdisk boot.img-ramdisk-new.cpio.gz --base 0x30000000 --pagesize 4096 -o boot.img.new

Looks like base / pagesize parameters are device dependent. Above are for Nexus S only

Example 1 - Unsecuring boot.img

After unpacking the img, we can chdir to unpacked ramdisk folder and change in default.prop:

ro.secure=1

to

ro.secure=0

EDIT: This example is useless, as someone pointed me how to properly gain root access with just running "adb root" and nothing else

Example 2 - Adding init.d support

At the end of init.rc we may add (if we also add busybox to system.img of course):

# Execute files in /etc/init.d before booting
service userinit /system/xbin/busybox run-parts /system/etc/init.d
    oneshot
    class late_start
    user root
    group root

Attach: mkbootimg.zip containing all needed tools

Made my day

Juan, the guy repairing my phone just gave me some excellent news. This is almost working...

Community is all that matters

This DHD community at XDA & HTCMania amazes me every day

A nice guy from UK offered me his spare DHD for free at XDA. I just received. Now I have to mix it up with my spare parts from the old device. Turns out that the same day I got the offering, another spanish guy from HTCMania offered his reparation services for free too.

Thank you guys, you are amazing.

Booting an unbootable Nexus S

Yes, I made it. A week later of getting a Nexus S device as a replacement for my broken DHD, I managed to brick it. "How come? These are unbrickable devices". Not true.

Most of todays phone devices have a NAND portion of the memory for holding the internal partitions of the device. As you may know, NAND memories can be written a finite (but supposedly large) number of times. Well, this second hand device holded exactly 5 boot flashes in one week. Ok, on average it may look high, but ... only five man. In absolute terms.

Internal memory layout
In my Nexus S this is the internal memory distribution. We access them through Memory Technology Layout linux subsystem:

/sdcard # cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00200000 00040000 "bootloader"
mtd1: 00140000 00040000 "misc"
mtd2: 00800000 00040000 "boot"
mtd3: 00800000 00040000 "recovery"
mtd4: 1d580000 00040000 "cache"
mtd5: 00d80000 00040000 "radio"
mtd6: 006c0000 00040000 "efs"

As you can see, there are several partitions, all of them accesible through /dev/mtd/mtd[0-6] special device.
And luckily for us boot and recovery has the same size. Some of them:

• bootloader : well, it has the bootloader. It's basically a small program with the ability to boot other partitions, as well as listening to "fastboot" commands over usb.
• boot : on a second stage, a kernel image plus a initrd (ram disk image) will be loaded from this partition. If this partition is corrpted, it will autoboot to recovery partition
• recovery : it is an alternate boot partition. It holds a kernel also, and an specialized initrd to perform some other recovery functions. You have here a mini-os and very important, an adb server that you can use to send adb commands over the usb.

Bootloader listens to fastboot commands: fastboot is a very interesting feature per se, on (almost) every android phone. There's a common protocol and a fastboot command on Android SDk, to tell the device to flash any partition with raw data, an even booting from an external image. If you can access to bootloader, you can recover from almost everything via fastboot commands.

What the hell happened
All you need to mess the things up is ... well, just flash something into MTD. With a sufficient number of flashes, anybody will eventually brick their devices. This is amazing, because at least since ICS (Android 4) every device will flash a default boot record into recovery partition. Every single time it boots

I was flashing a new custom kernel through recovery when I noticed a failure. Properly looking at the recovery.log file, I could notice a failure on several blocks of the partition.

flashing boot from /sdcard/clockworkmod/backup/2011-12-24.18.28.01-CM9-18+g2//boot.img
mtd: successfully wrote block at 0
mtd: successfully wrote block at 40000
mtd: successfully wrote block at 80000
mtd: successfully wrote block at c0000
mtd: successfully wrote block at 100000
mtd: successfully wrote block at 140000
mtd: successfully wrote block at 180000
mtd: successfully wrote block at 1c0000
mtd: successfully wrote block at 200000
mtd: successfully wrote block at 240000
mtd: successfully wrote block at 280000
mtd: successfully wrote block at 2c0000
mtd: not writing bad block at 0x00300000 (ret 1 errno 2)
mtd: not writing bad block at 0x00340000 (ret 1 errno 2)
mtd: successfully wrote block at 380000
mtd: successfully wrote block at 3c0000
mtd: successfully wrote block at 400000
mtd: successfully wrote block at 440000
mtd: successfully wrote block at 480000
mtd: successfully wrote block at 4c0000
mtd: successfully wrote block at 500000
mtd: successfully wrote block at 540000
mtd: successfully wrote block at 580000
mtd: successfully wrote block at 5c0000
mtd: successfully wrote block at 600000
mtd: successfully wrote block at 640000
mtd: successfully wrote block at 680000
mtd: successfully wrote block at 6c0000
mtd: successfully wrote block at 700000
mtd: successfully wrote block at 740000
mtd: successfully wrote block at 780000
mtd: successfully wrote block at 7c0000
error writing bootError while flashing boot image!mtd: successfully wrote block at 0

The problem can be reproduced any time, just by flashing any boot.img file (for instance from a recovery backup file):

flash_image boot boot.img

Partially solving it: boot through fastboot
Fastboot has a special mode for booting an image from the PC itself. It will push the image to a temporary memory segment, and boot to it. Without flashing. It can be done with this command on the PC:

fastboot boot boot.img

This solution is nice, but you will need a PC every time you need to reboot your phone. And I tend to do that ... well, a few times a day.

Definitive solution
The easiest solution I could find was: flashing boot.img over the recovery partition.
It should work as the boot procedure described above goes through both boot and recovery partition.

/sdcard # flash_image recovery boot.img.orig
flashing recovery from boot.img.orig
mtd: successfully wrote block at 0
mtd: successfully wrote block at 40000
mtd: successfully wrote block at 80000
mtd: successfully wrote block at c0000
mtd: successfully wrote block at 100000
mtd: successfully wrote block at 140000
mtd: successfully wrote block at 180000
mtd: successfully wrote block at 1c0000
mtd: successfully wrote block at 200000
mtd: successfully wrote block at 240000
mtd: successfully wrote block at 280000
mtd: successfully wrote block at 2c0000
mtd: successfully wrote block at 300000
mtd: successfully wrote block at 340000
mtd: successfully wrote block at 380000
mtd: successfully wrote block at 3c0000
mtd: successfully wrote block at 400000
mtd: successfully wrote block at 440000
mtd: successfully wrote block at 480000
mtd: successfully wrote block at 4c0000
mtd: successfully wrote block at 500000
mtd: successfully wrote block at 540000
mtd: successfully wrote block at 580000
mtd: successfully wrote block at 5c0000
mtd: successfully wrote block at 600000
mtd: successfully wrote block at 640000
mtd: successfully wrote block at 680000
mtd: successfully wrote block at 6c0000
mtd: successfully wrote block at 700000
mtd: successfully wrote block at 740000
mtd: successfully wrote block at 780000
mtd: successfully wrote block at 7c0000
mtd: successfully wrote block at 0
/sdcard # reboot

Alternative solutions... (not tested)
Some people shrink their kernels so they can fit on the working space. It left me 2.8Mb. I made in fact a boot.img with that size, but after the kernel and ramdisk there is some more data that I haven't figured it out yet what it does... or perhaps it's a padding problem or something. Don't know. It didn't worked.

Some other people actually remaps the memory layout, with a new definition of partitions... http://forum.xda-developers.com/showthread.php?t=704560

The most radical is to have a custom bootloader: http://forum.xda-developers.com/showthread.php?t=1233273


Caveats
Well, I don't have a recovery anymore. But I can boot into one from the PC. And that's much more unlikely to happen that having turn boot the phone itself. It would be done with:

fastboot boot clockwordmod-whatever-version.img

Conclusions
I'm not sure if this change in ICS is intended or not from google ... but flashing the recovery partition on every single reboot seems no good to me. Maybe they are trying to burn your NAND  making impossible to upgrade the OS? Don't think so but ... who knows. People happy with their devices for a long time is not a good commercial policy... Anyway, it is good practice to remove that (/system/etc/flash_recovery.sh on stock ICS) and have backups of all your partitions, in fastboot (raw) format. And always a PC with fastboot and ADB ready ;-)

Thoughts about buying a new device...

As some people may already know, my beloved DHD is dead (details here )

I've been thinking about my options now. The following post is a collection of random thoughts and rants. This is not a call for money, not even close. In fact this is the opposite thing: let me explain.

There are a lot of people interested in me having another DHD to continue development of BlackICE. This would be a good (and fair) option, first because it is still a great device and second because it has one of the best communities on XDA. There is one of the most active devices on ICS and I was lately thinking in targeting to a BlackICE ICS build.

These people has been generously giving me some money in the aim of me buying this device again. I am very grateful for that. On the other side, of course as a gadget enthusiast and developer I would like to have some new hardware to experiment with.

As I don't want pressure for taking a decision, I have just decided to return money for any post-dhd-mortem donation. It is the fair thing to do, as I'm not developing nothing for DHD right now.

The problem is the usual: budget.

When I got my DHD it was at a very very low price. About 100 euros. That price a year ago was insanely low. Why? At least in my country, some operators offer their devices at a very reduced price at a cost of keeping you as a customer for almost 2 years. Yes: I have to keep my operator for the next year. If I manage to break, loose or brick my phone, I'm on my own... and still paying monthly data fees without an internet device!

On the other side, if I buy some DHD in the free market, it costs around 400-500 €. That is about 50 € less than a SGS2. Or 150 € less than a Galaxy Nexus.

So to end with this rant: I don't want money from users. There's not enough money to buy a new DHD, and i think it doesn't worth it. And I don't want partial donations of people with expectations about me having again a DHD.

The most probable thing is: If i get into negotiations with the operator and manage to get a new device, that's what I will do. First thing I asked for is another DHD for a reduced price, but there's no stock of DHD with this formula.

If not, I would buy a second hand device. I'm negotiating with some people to get a SGS2 for around 300 €. I prefer to buy one 2nd hand SGS2 for 300 than a 2nd hand DHD for almost the same price.

My third option (and it is the more likely to happen) is to buy an outdated android device in the meantime. I have an offer for a Nexus S (not so outdated!) for 150 € but I think I can get it for 100€. Nexus S is a great device, only 256 MB RAM less than DHD and an ICS OTA coming these days.

The option I chose is irrelevant for DHD community. My development will be focused on ICETool and I will be always willing to help the people asking in the thread.