HanishKVC’s General Blog zone

February 28, 2010

Android AOSP for G1 ADP1 HTC Dream

Filed under: Android,Blogroll,linux,OpenSource,technology — hanishkvc @ 10:56 pm

Android AOSP for G1 / ADP1 / HTC_Dream
v01March2010, HanishKVC, Feb2010

This document gives the Steps required to build Android AOSP for ADP1/HTC Dream/G1 phone.

>> Current status: Basic kernel (boot), wifi and system image is working.
Not sure of 3D and Calender,Contact(with Google sync) [Googleloginservice?] <<

Building Android Donut release using
the Ubuntu Karmic (9.10) i386 as the development / host machine

***N*** Preparing the system

We require to get java5 jdk, which is required by Android, installed into Ubuntu 9.10. But by
default 9.10 comes with Java6, so we pick up the Java5 from 9.04. To do this we require to
add the below lines to /etc/apt/sources.list as a root user (or by using Software sources gui).

Also we require to setup a udev rule to help with debugging of the Android devices,The example
below is for HTC devices, for other manufactures, replace with appropriate vendor id.

$sudo bash
# echo “deb http://mirrors.us.kernel.org/ubuntu/ jaunty multiverse” >> /etc/apt/sources.list
# echo “deb http://mirrors.us.kernel.org/ubuntu/ jaunty-updates multiverse” >> /etc/apt/sources.list

# echo ‘SUBSYSTEM==”usb”, SYSFS{idVendor}==”0bb4″, MODE=”0666″‘ >> /etc/udev/rules.d/51-android.rules

# exit
$ sudo update

Next we require to Get the required build and support applications installed

$ sudo apt-get install git-core gnupg sun-java5-jdk flex bison gperf libsdl-dev libesd0-dev libwxgtk2.6-dev build-essential zip curl libncurses5-dev zlib1g-dev

***N*** Getting the repository and the code, setup

We require to install the repo program, which is used by Google as the application to manage their code repository and work flow.

$ mkdir ~/bin
$ export PATH=~/bin:$PATH

$ curl http://android.git.kernel.org/repo >~/bin/repo
$ chmod a+x ~/bin/repo
$ mkdir ~/work/aosp_donut
$ cd ~/work/aosp_donut

$ repo init -u git://android.git.kernel.org/platform/manifest.git -b donut

NOTE: If you want to work with the master branch, then don’t give -b option to repo init
NOTE: However I haven’t had success with master build as it stands on 22Feb2010, have to check why.

>>ALTERNATIVE FOR Cyanogen’s repo, haven’t tried yet<< $ repo init -u git://github.com/cyanogen/android.git -b donut

$ repo sync

***N*** Getting and preparing the proprietry stuff from HTC

FILE1: htc-adp1.sfx.tgz

This file is available has “HTC Proprietary Binaries for ADP1” from

Download this file and copy it into ~/work/aosp_donut/vendor/htc/dream-open

FILE2: signed-dream_devphone_userdebug-ota-14721.zip

This file is available from

Download this file to the root of your android repository i.e ~/work/aosp_donut

$ cd ~/work/aosp_donut/vendor/htc/dream-open
$ tar -zxvf htc-adp1.sfx.tgz
$ ./htc-adp1.sfx

Note: Not sure if htc-adp1.sfx is required, because looking at unzip-files.sh, it seems like it should work even with out this??? Have to check

$ ./unzip-files.sh

***N*** Fixing some bugs in code (rather stricter compiler related issues)

development/emulator/qtools/trace_reader.cpp:1012: error: invalid conversion from ‘const char*’ to ‘char*’
development/emulator/qtools/trace_reader.cpp:1015: error: invalid conversion from ‘const char*’ to ‘char*’
SOLUTION: Replace the char* defs with const char* definitions.

development/emulator/qtools/dmtrace.cpp:166: error: invalid conversion from ‘const char*’ to ‘char*’
development/emulator/qtools/dmtrace.cpp:183: error: invalid conversion from ‘const char*’ to ‘char*’
SOLUTION: Type cast the assignments with (char *)

NOTE: donut_plus_aosp – seems to fix these bugs, but has other large changes also, haven’t tried it yet.
NOTE: Also not sure wrt Video/Audio codec h/w accel optimized modules in donut_plug_aosp

***N*** Building the code

Now that the source code is available and setup with propriotory binary stuff from htc, let us start the actual build

$ cd ~/work/aosp_donut

$ source build/envsetup.sh
$ lunch aosp_dream_us-eng

$ make -j4

Now the generated files (boot.img, recovery.img, system.img, userdata.img) will be available at out/target/product/dream-open/

***N*** Check out this Source compiled User space (system.img) with prebuild kernel based boot.img

$ cd ~/work/aosp_donut/out/target/product/dream-open
$ rm recovery.img <=> In case you want to replace it with your favorite recovery image
$ cp /path/to/recovery_cyanogenmod_amon_ra.img recovery.img   <=>  This replaces the default recovery image with one which you want

Put device into FASTBOOT mode (reboot/power_on the device with BACK key pressed, it should show the driods on skateboard with fastboot text displayed)

$ fastboot devices
$ fastboot erase userdata   <=>   similarly boot and cache
$ fastboot -p dream-open -w flashall
$ fastboot flash userdata userdata.img
$ fastboot reboot

***N*** Compiling android kernel source for Dream/Adp1/G1

*** Get the kernel source
$ cd ~/work/kernel

$ git clone git://android.git.kernel.org/kernel/msm.git
$ cd msm
$ git branch -r
$ git checkout -b android-msm-2.6.29 origin/android-msm-2.6.29

*** Setup the path to point to appropriate compiler tool chain

$ export PATH=$PATH:~/work/aosp_donut/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin

*** config the kernel

OPTION 1: Get the default config options for the kernel from what is already specified in kernel source wrt adp1

$ make msm_defconfig   <=> Rather use the next command to be safe
$ make ARCH=arm CROSS_COMPILE=arm-eabi- msm_defconfig

OPTION 2: Get the config from a phone running android

$ adb pull /proc/config.gz .
$ gunzip config.gz
$ mv config .config

*** Build the kernel

$ make ARCH=arm CROSS_COMPILE=arm-eabi-

The kernel will be in arch/arm/boot/

*** Move the kernel to Android platform source directory

$ cp ~/work/kernel/msm/arch/arm/boot/zImage ~/work/aosp_donut/vendor/htc/dream-open/kernel

Now building the android platform will use this new kernel to build the boot.img and recovery.img
NOTE: Differ building the android platform, if you want to update wifi module (wlan.ko) also

*** Build the wifi module to match the new kernel and copy it to appropriate platform directory

$ cd ~/work/aosp_donut/system/wlan/ti/sta_dk_4_0_4_32
$ export KERNEL_DIR=~/work/kernel/msm

$ make  <=> OR the next line
$ make KERNEL_DIR=~/work/kernel/msm ARCH=arm CROSS_COMPILE=arm-eabi-

$ cp ~/work/aosp_donut/system/wlan/ti/sta_dk_4_0_4_32/wlan.ko ~/work/aosp_donut/vendor/htc/dream-open/

NOTE: Looking at the comment in the wlan/ti/ … directory, there seesm to be another way
of getting this to autocompile but at this time I am not sure how that will work out

Now building the android platform will use this new wlan.ko to build the system.img (/system/lib/modules/wlan.ko)

*** Building the Android platform with new kernel and wifi module (already copied to the required locations)

$ cd ~/work/aosp_donut
$ source build/envsetup.sh
$ lunch   <=> remember to select appropriate target
$ make -j2

***N*** Burning the new images

$ export PATH=~/work/aosp_donut/out/host/linux-x86/bin:$PATH

Boot the device into fastboot mode by powering on the device by holding BACK button pressed.
You should see the droids on skateboards and also fastboot specified on the screen
Connect the usb cable between device and host, if not already done so

* On the host pc do (IF ONLY UPDATING boot.img)

$ fastboot devices  <=> This should list your device
$ fastboot erase boot
$ fastboot flash boot boot.img
$ fastboot reboot

* On the host pc do (IF burning everything i.e all imgs (boot,recovery,system,userdata)

$ fastboot devices
$ fastboot erase boot
$ fastboot erase userdata <=> This is just in case for future
$ fastboot erase cache <=> This is just in case for future
$ fastboot -p dream-open -w flashall
$ fastboot flash userdata userdata.img
$ fastboot reboot

* Now the phone should have rebooted into Android with the new kernel/system which we just burnt. Check it out by looking into Settings->About phone

$ adb devices  == This should list your device
$ adb shell    == Now you have root access to your device

***N*** Burning into G1 (using recovery image)

Copy the boot.img and system.img to root of sdcard in G1
Boot your G1 into recovery mode by powering on the G1 with HOME button pressed.
Getting into the console.

$ mount /sdcard
$ flash_image boot /sdcard/boot.img
$ flash_image system /sdcard/system.img

NOTE: This didn’t work. May be because I didn’t erase userdata and load new userdata ???. Have to check this later.

Repo querieis

** I don’t see a direct way of finding which branch is setup by repo init, other than by looking at .repo/manifest.xml file. Am I missing something, or is it how one looks.

** I see 2 different manifest files for donut. And am not able to find a simple way of telling which of the donut manifests is used by default and how to change it if required. Or am I interpreting something wrongly here.

** Also no direct info has to what release tag/branch corresponds to what at a high level (like difference between donut and donut_aosp_plus – also had to look at .repo/manifests.git/FETCH_HEAD to find the branches available)

** Also the google repo usage document assumes that the developer understands git/repo too much (i.e a novice will require to dig lot more). They could help by making the document bit more verbose and or more importantly adding some use cases.

Useful links



Experiment status till date
>>Attempt 1: FAILED<< when trying with the Google android.git.kernel.org repository
a1.1 – Used master branch instead of donut
a1.2 – Did not use htc-adp1.sfx.gz (because unzip-files.sh seems to work around this)
a1.3 – Used the prebuilt kernel which is already part of the repository. And which in turn is automatically used to create boot.img
a1.4 – used flash_image boot boot.img and flash_image system system.img from cm’s recovery console
a1.5 – targetted aosp_dream_us-eng

>>Attempt 2: Basic kernel(compiled locally), wifi (locally compiled) and system apps running << Tried with donut branch this time.
a2.1 – Used donut branch

>>Attempt 3: Have to try donut_plus_aosp<<

>>Attempt 4: ToDo << Later have to try with cyanogen’s repository.
When trying to search for any steps to get aosp compiled for G1, I have come across few pages by ctso also (which is linked above).
As I have some issues with Cyanogenmod build, I want to stick with Google aosp code for now. So haven’t given Cyanogen’s repository a try yet.

May 16, 2007

Short and simple commandline Bluetooth in any new Linux distros

Filed under: bluetooth,debian,linux,Nokia,OpenSource,technology — hanishkvc @ 7:22 pm

Yesterday I had to transfer some files/S60 Opensource programs to my Nokia 6630 mobile and so picked up my usb bluetooth dongle (after ages) and connected to my Linux PC to achieve the same. I had forgotten the things which I had done long time back to get it working (Also one of these days I have to find out where I had noted those steps down).

Either way I started by remembering that I have to try and use obex logic to put those files on the mobile (now come on remembering that isn’t that difficult;-). Soon I remembered most of the things to do through aptitude search/show bluetooth/bluetooth packages, dpkg -L <bluetooth related packages>, some trail_N_error and net searching (googling).

But to my horror what ever I do the connection wouldn’t establish has the bluetooth stack on the PC wasn’t pickup the PIN which I just configured on the PC. After some more rtfm and dpkg -L bluez-utils and cross verification on the bluez website I realised that the way the PIN to be used is specified to the bluetooth stack has changed on the PC and now instead of the pin_handler it uses a dbus based passkey handler. So I compiled the given passkey_agent.c and resolved it. And thus could achieve the file transfer without going into windows thou with some deficit of sleep 😉

So here are the commands one could use to work with bluetooth devices in a linux based pc =>

– Gives info about the bluetooth hci on your pc
– Ensure the device is up and running and has required scan modes
– hcitool dev should also give some of this info

hcitool inq and hcitool scan
– Gives info about or rather identifies nearby bluetooth devices

hcitool info <BTAddr>
– Get info about remote bluetooth device

l2ping <BTAddr>
– One way to see if we can communicate with a remote bluetooth device

sdptool browse <BTAddr> or sdptool records <BTAddr>
– Gives info about the services provided by a remote bluetooth device

obexftp –nopath –noconn –uuid none –bluetooth <BTAddr> –channel <OPUSHChann
elNo> –put <FileToPut>
– Allows one to send file without specifying the pin on the remote device side
– The OPush channel number for device is got from sdptool above

passkey-agent –default <Pin>
– Pin specified here is what the remote BT device should provide
or its user enter on that device when requested.

obexftp -b <BTAddr> -v -p <FileToPut>
– Allows one to put a file onto the specified BT device
– obexftp could also be used to get or list the files on the BT device
– also allows one to identify a nearby BT device by just giving -b option

– Allows one to recieve files sent from a bluetooth device.
– Depending on who started it, the recieved files will be stored in the corresponding home directory

Note: The old style pin_handler doesn’t work with latest bluez, you require a
dbus based passkey handler and there is one provided by default by bluez-utils
called passkey-agent
Hope this helps anyone who is trying to use bluetooth devices from the commandline on a new linux distro, as well as it would help me to remember for the future for my own use.

Create a free website or blog at WordPress.com.