Replicant

h1. Porting Guide: MSM/QSD

h2. Introduction

Many people bought many different phones, and some of them whish to help replicant and/or to port replicant to their phones or devices.

This guide will show what was done for the htc dream, so these people can understand the process better.

When talking about porting, this page talks about re-using existing product definitions. You will not learn how to

build Android for a device not currently supported by Android. Instead, you will learn how to build a version of

[Cyanogenmod http://www.cyanogenmod.com/] without proprietary parts.

To gain more insight in the Android build system, refer to "Android Build System documentation":http://source.android.com/porting/build_system.html which is part of

"Android Platform Developer's Guide":http://source.android.com/porting/. You should find an answer there if you have any questions about the Makefiles referenced in this document.

Note: The Android Build System documentation above has been removed. You can find a mirror of the (outdated) documentation "here":http://www.kandroid.org/online-pdk/guide/index.html and "here":http://www.netmite.com/android/mydroid/development/pdk/docs/.

h2. Terminology

The RIL is the radio interface library, that is to say, a library that talks to the modem, usually (but not always) trough AT commands.

Basically the modem runs on a separate CPU,and there is some sort of communication needed between the main CPU and the modem CPU to make telephony work. For instance, the modem must tell you when you've got a call, and you must tell the modem that you want to call someone.

TODO: point to 0707 standard or newer

h2. Help with source code

Keep in mind that on most devices, the full source code of the kernel is released.

However, some userspace libraries, or dlopened libraries (libraries loaded at runtime after the application started) are proprietary software,

so if you're porting to a new CPU/SOC keep in mind that you have the source code to the kernel interfaces.

That can help a lot, and sometimes there is even some sort of documentation in the headers.

h2. Build the source

The first thing to do is to download the replicant sources:

[[BuildDream]] can be used as a reference: download and build the sources for your device.

Let's say the user has a HTC Wildfire. It is useful to know the codename of the device in question, which is "Buzz" in case

of the Wildfire.

You need to configure the build tree for our device. By default, a generic image

for the Android emulator will be built. 

In [[BuildDream]], you would use the following command to set up the build:

<pre>

lunch cyanogen_dream_sapphire-eng 

</pre>

Now, since you are not building for the HTC dream, you need to identify the right command that corresponds to your device.

In order to do that, run the following command and look at its output.

<pre>

$ source build/envsetup.sh

including device/geeksphone/one/vendorsetup.sh

including device/htc/ace/vendorsetup.sh

including device/htc/bravoc/vendorsetup.sh

including device/htc/bravo/vendorsetup.sh

including device/htc/buzz/vendorsetup.sh

including device/htc/glacier/vendorsetup.sh

including device/htc/heroc/vendorsetup.sh

including device/htc/inc/vendorsetup.sh

including device/htc/legend/vendorsetup.sh

including device/htc/liberty/vendorsetup.sh

including device/htc/supersonic/vendorsetup.sh

including device/htc/vision/vendorsetup.sh

including device/motorola/sholes/vendorsetup.sh

including device/nvidia/harmony/vendorsetup.sh

including vendor/cyanogen/vendorsetup.sh

</pre>

The last line is important:

<pre>

$ cat vendor/cyanogen/vendorsetup.sh

add_lunch_combo cyanogen_ace-eng

add_lunch_combo cyanogen_bravo-eng

add_lunch_combo cyanogen_bravoc-eng

add_lunch_combo cyanogen_buzz-eng

add_lunch_combo cyanogen_dream_sapphire-eng

add_lunch_combo cyanogen_espresso-eng

add_lunch_combo cyanogen_glacier-eng

add_lunch_combo cyanogen_harmony-eng

add_lunch_combo cyanogen_hero-eng

add_lunch_combo cyanogen_heroc-eng

add_lunch_combo cyanogen_inc-eng

add_lunch_combo cyanogen_legend-eng

add_lunch_combo cyanogen_liberty-eng

add_lunch_combo cyanogen_one-eng

add_lunch_combo cyanogen_passion-eng

add_lunch_combo cyanogen_sholes-eng

add_lunch_combo cyanogen_supersonic-eng

add_lunch_combo cyanogen_vibrant-eng

add_lunch_combo cyanogen_vision-eng

add_lunch_combo cyanogen_z71-eng

PATH=$PATH:$PWD/vendor/cyanogen/tools ; export PATH

</pre>

The output include the list of supported (by cyanogenmod) devices.

For instance if you have the Wildfire (codename 'buzz') phone do:

<pre>

lunch cyanogen_buzz-eng

</pre>

Then build the source, backup what's on your device, including the operating system, and flash the new replicant image.

Then test what works and what doesn't.

The images are located in 

<pre>

out/target/product/dream_sapphire

</pre>

in the case of the HTC Dream. You need to look in the path that corresponds to your device.

h2. Trying free replacements

The source code you just built contains some free replacements for the proprietary

libraries shipped by your phone vendor with the default firmware.

A list of proprietary libraries is available in

<pre>

device/htc/dream_sapphire/extract-files.sh

</pre>

Note: don't run this file, just look at it. If you run it, the proprietary files will be copied from your phone into the build tree. A build containing proprietary files would put you and

your users at risk. Additionally, it is illegal to redistribute such build, because the libraries are not redistributable(the copyright owner didn't allow you to redistribute them).

h3. RIL test

I will take the example of how to use the free RIL (Radio Interface Library) to see if it works fine without modifications:

The proprietary RIL library (which you don't have in the phone) location is found looking at the extract-files.sh

here's a part of extract-files.sh:

<pre>

adb pull /system/lib/libhtc_ril.so ../../../vendor/htc/$DEVICE/proprietary/libhtc_ril.so

</pre>

Note: don't run this command, just look at it. If you run it, the proprietary files will be copied from your phone into the build tree. A build containing proprietary files would put you and

your users at risk. Additionally, it is illegal to redistribute such build, because the libraries are not redistributable(the copyright owner didn't allow you to redistribute them).

So looking at the above line the proprietary RIL is located here on the phone:

<pre>

/system/lib/libhtc_ril.so

</pre>

while the free ril is located here (known fact):

<pre>

/system/lib/libreference-ril.so

</pre>

In order to test the free RIL you could be tempted to do that:

<pre>

# ./adb remount

# ./adb shell

mv /system/lib/libreference-ril.so /system/lib/libhtc_ril.so

</pre>

But that wouldn't work as it wouldn't be using the right serial port, the correct way to try that is to use getprop/setprop:

<pre>

# ./adb shell

# setprop

usage: setprop <key> <value>

</pre>

What you can do to set the libre RIL is - possibly - this:

<pre>

./adb shell

setprop rild.libpath /system/lib/libreference-ril.so

setprop rild.libargs -d/dev/smd0

</pre>

Here's how it looks on a working replicant on the HTC Dream:

<pre>

# ./adb shell

# getprop | grep ril

[ro.ril.hsxpa]: r2

[ro.ril.gprsclass]: r10

[rild.libpath]: [/system/lib/libreference-ril.so]

[rild.libargs]: [-d/dev/smd0]

[init.svc.ril-daemon]: [running]

[ro.ril.def.agps.mode]: r2

[gsm.version.ril-impl]: [android reference-ril 1.0]

</pre>

* /dev/smd0 is the (emulated) serial port

* /system/lib/libreference-ril.so is where to look for the RIL hardware specific library 

Then, you can kill the ril daemon:

<pre>

./adb shell killall rild

</pre>

Then try the reference RIL. You can see debugging things and such by doing:

<pre>

./adb logcat -b radio

</pre>

That's also tested and worked on the gtklocker's HTC Hero, so I suppose it will work for the most HTC devices out there. If your device isn't listed anywhere, don't dare to try it.

h2. Replacing proprietary libraries for real

On the HTC Dream the following proprietary libraries were replaced:

(Refer to [[ProprietaryHtcDreamLibsReplacement]] for more up to date details(or fix it if it's less recent))

The first thing you will have to do is to modify the build system.

The key thing to do is to change 

h3. RIL

h4. Android Reference RIL

If the RIL you previously tried works fine, why not switching to it...directly in the build system.

Here's the diff between A working RIL and a non-working RIL for the htcdream:

<pre>

android_device_htc_dream_sapphire$ git diff 5593d2899203ec378c306701788f1c43af9a6935 -- full_dream_sapphire.mk

diff --git a/full_dream_sapphire.mk b/full_dream_sapphire.mk

index 9ec7feb..eb1b956 100644

--- a/full_dream_sapphire.mk

+++ b/full_dream_sapphire.mk

@@ -40,7 +40,8 @@ PRODUCT_PROPERTY_OVERRIDES := \

     ro.media.dec.jpeg.memcap=10000000

 PRODUCT_PROPERTY_OVERRIDES += \

-    rild.libpath=/system/lib/libhtc_ril.so \

+    rild.libpath=/system/lib/libreference-ril.so \

+    rild.libargs=-d/dev/smd0 \

     wifi.interface=tiwlan0

 # Time between scans in seconds. Keep it high to minimize battery drain.

</pre>

Note that full_dream_sapphire.mk is located here:

<pre>

device/htc/dream_sapphire/full_dream_sapphire.mk

</pre>

The diff is self-explanatory and how to do the change is left as an exercise to the reader.

In case the RIL need to be modified the sources are in :

<pre>

hardware/ril/reference-ril

</pre>

They are written in C.

h4. HTC Generic RIL

Another RIL has been written for MSM devices originally running Windows Mobile and is used on the Replicant project as it works better than the Android reference RIL on most devices.

* It's originally hosted at: "https://gitorious.org/xdandroid/hardware_xdandroid-ril":https://gitorious.org/xdandroid/hardware_xdandroid-ril

* We made a copy of this with some modifications there: "https://gitorious.org/replicant/hardware_xdandroid-ril":https://gitorious.org/replicant/hardware_xdandroid-ril

*hardware/ril/libhtcgeneric-ril/Android.mk* :

<pre>

BUILD_HTCGENERIC_RIL := false

ifeq ($(TARGET_BOARD_PLATFORM),qsd8k)

  BUILD_HTCGENERIC_RIL := true

else ifeq ($(TARGET_BOARD_PLATFORM),msm7x30)

  BUILD_HTCGENERIC_RIL := true

else ifeq ($(TARGET_BOARD_PLATFORM),msm7k)

  BUILD_HTCGENERIC_RIL := true

endif

</pre>

Then, on your device configuration, switch:

@rild.libpath=/system/lib/libreference-ril.so@

to:

@rild.libpath=/system/lib/libhtcgeneric-ril.so@

h3. Audio libraries

On the HTC dream the audio libraries were modified.

If your device is an msm7k "CPU" (in reality it's called a SOC, or system on a chip), it already contain "the routing fix":http://gitorious.org/replicant/android_hardware_msm7k/commit/e0b55a19b2fc004915503ebdfd7c4c02c4264611.

Note several things on "the commit":http://gitorious.org/replicant/android_hardware_msm7k/commit/e0b55a19b2fc004915503ebdfd7c4c02c4264611:

* the routing was disabled, I had to re-enable it

* I had to replace some non-existant functions, for that I used public playwav2.c source code that the author released to us under the apache 2.0 license.

* I had nearly no knowledge of C++

* it was easy

On the nexus one the proprietary libacoustic libraries are only used for bluetooth(all the rest works if you pushed the firmwares).

On the dream (msm7k), libacoustic has been fully replaced, see "it loads the values from the /system/etc/AudioPara4.csv CSV file to MSM shared memory, which fixes in-call volume regulation and adds support for No Mic Wired Headset. It should also add support for other other things (probably including bluetooth devices) but this has not been tested yet. 

The existing replacement code (hardware/msm7k/libaudio/AudioAcoustic.cpp) should work for your msm7k device but it has only been tested on the Dream. 

*Note that (even if unconfirmed) it should more likely work the same way for every msm7k device, so try the code without any modification first and do the following steps only if the code does not work for your msm7k device! *

If it does not work, check that your device contains the /system/etc/AudioPara4.csv CSV file. If it does not, the file may have another name, then you should modify replicant code to use the filename of your device and test if it works.

If you don't see any CSV file anywhere, then your device must not work like HTC Dream and you'll probably have to write the code to support acoustic or find another working replacement. You can read jbruneaux's work on audio acoustic for WinCE devices from @git://gitorious.org/~jbruneaux/xdandroid/hardware_msm7k_libacoustic.git@ (userland) and @git://gitorious.org/linux-on-qualcomm-s-msm/linux-msm-home-work.git@ branch @htc-msm-2.6.27-libacoustic@ (kernel-space). Note that audio acoustic is not absolutely necessary to make audio work, it'll just cause some minor issues as written above. 

To make sure it parses the CSV file, run adb logcat | grep Audio and find the following lines: 

<pre>

D/AudioAcousticMSM72XX(  122): Successfully opened /system/etc/AudioPara4.csv

D/AudioAcousticMSM72XX(  122): CSV Header: Dream_TMU_20090305

D/AudioAcousticMSM72XX(  122): Read:

D/AudioAcousticMSM72XX(  122): 24 Audio_Path_Table entries

D/AudioAcousticMSM72XX(  122): 24 Audio_Path_Uplink_Table entries

D/AudioAcousticMSM72XX(  122): 35 Phone_Acoustic_Table entries

D/AudioAcousticMSM72XX(  122): 35 BT_Phone_Acoustic_Table entries

D/AudioAcousticMSM72XX(  122): 24 HTC_VOC_CAL_CODEC_TABLE_Table entries

D/AudioAcousticMSM72XX(  122): 0 CE_Acoustic_Table entries

</pre>

Then, if it parses the file but does not work, it's probably because the addresses (or the size) where the tables must be written in MSM shared memory are not the same for the Dream and for your device. 

In order to find the correct addresses, you'll have to use CyanogenMod code with the non-free libhtc_acoustic.so lib that you can get from CyanogenMod downloadable zip for your device.

move the hardware/msm7k/ directory to another place '''not in the build tree''' or it'll fail (@ mv hardware/msm7k/ ../msm7k @.

Then download CyanogenMod code:

@git clone git://github.com/CyanogenMod/android_hardware_msm7k.git -b froyo-stable hardware/msm7k/@

Now you need to modify the kernel-side driver to print some useful infos on file kernel-msm/arch/arm/mach-msm/htc_acoustic.c, function acoustic_mmap(), add the following code:

<pre>

D(" -- vma dump start --\n");

D("vm_start=%x (%d)\n", vma->vm_start, vma->vm_start);

D("vm_end=%x (%d)\n", vma->vm_end, vma->vm_end);

D("vm_page_prot=%x (%d)\n", vma->vm_page_prot,vma->vm_page_prot);

D("vm_flags=%x (%d)\n", vma->vm_flags, vma->vm_flags);

D("vm_pgoff=%x (%d)\n", vma->vm_pgoff, vma->vm_pgoff);

D(" -- vma dump end --\n");

</pre>

Then build the code (make -j9 bootimage && make-j9 systemimage), and flash system.img and boot.img to your device, boot it, copy the libhtc_acoustic.so lib to /system/lib/ (you need to remount /system using @adb remount@ to write under /system) and check the kernel logs with @adb shell dmesg | grep acoustic@. You should see something like:

<pre>

<6>[   22.250274] htc-acoustic: open

<6>[   22.252716] htc-acoustic: mmap

<6>[   22.253265] htc-acoustic:  -- vma dump start --

<6>[   22.254028] htc-acoustic: vm_start=4010c000 (1074839552)

<6>[   22.254699] htc-acoustic: vm_end=40119000 (1074892800)

<6>[   22.255310] htc-acoustic: vm_page_prot=38f (911)

<6>[   22.256011] htc-acoustic: vm_flags=400844ff (1074283775)

<6>[   22.256622] htc-acoustic: vm_pgoff=1f4a (8010)

<6>[   22.257293] htc-acoustic:  -- vma dump end --

<6>[   22.742675] htc-acoustic: ioctl

<6>[   22.743103] htc-acoustic: ioctl: ACOUSTIC_ARM11_DONE called 123.

<6>[   22.746612] htc-acoustic: ioctl: ONCRPC_ACOUSTIC_INIT_PROC success.

<6>[   22.747344] htc-acoustic: release

</pre>

Now you can get the size of the dedicated memory area: vm_end - vm_start = 0x40119000 - 0x4010c000 = *0xd000*.

Then, you'll have to dump the entire memory to a file that you need to create: @adb shell touch /data/dump@. Add a function to AudioHardware.cpp :

<pre>

void acoustic_mmap_dump(void)

{

	uint8_t *test_map_base;

	uint8_t *ptr, nval;

	int fd, fdd=0;

	off_t [[TargetAddr]];

	int len;

	fd = open("/dev/htc-acoustic", O_RDWR | O_SYNC);

	fdd = open("/data/dump", O_RDWR | O_TRUNC | O_CREAT);

	test_map_base = (uint8_t *)

	    mmap(0, 0xd000, PROT_READ | PROT_WRITE, MAP_SHARED, fd,

		 0);

//	test_virt_base = test_map_base + (TargetAddr & MAP_MASK);

//	LOGD("virtual base at %p (phys=0x%X)\n", test_virt_base, [[TargetAddr]]);

	LOGD(" -- htc-acoustic memory read -- \n");

	LOGD("beginning adress is@%p\n", test_map_base);

          for (len = 0; len < 0xd000; len++)

		{

			if( write(fdd, test_map_base, sizeof(uint8_t) ) < 0)

			{

				LOGE("write failed");

				break;

			}

			//LOGD("0x%x (%d) @%p",  *(test_map_base), *(test_map_base), test_map_base);

		  test_map_base++;

		}

	munmap(test_map_base, 0xd000);

	close(fdd);

	close(fd);

}

</pre>

replace 0xd000 by the size you found out and call it after @int rc = set_acoustic_parameters();@ on the AudioHardware::AudioHardware() function.

Build the code (make -j9 systemimage), flash system.img to your device and get /data/dump: @adb pull /data/dump@. This should copy dump to your current directory. You can try to load that file in MSM shared memory at the exact place where you dumped it. To do that, add the following functions to AudioHardware.cpp (don't forget to replace the size, 0xd000 if it's different for your device):

<pre>

#define ACOUSTIC_IOCTL_MAGIC 'p'

#define ACOUSTIC_NOTICE		_IOW(ACOUSTIC_IOCTL_MAGIC, 42, unsigned int)

#define ACOUSTIC_ARM11_DONE	_IOW(ACOUSTIC_IOCTL_MAGIC, 22, unsigned int)

void acoustic_mmap(void)

{

	char *test_map_base;

	volatile int *ptr, nval;

	int fd, fdd;

	off_t [[TargetAddr]];

	int len;

	fd = open("/dev/htc-acoustic", O_RDWR | O_SYNC);

	fdd = open("/data/dump", O_RDWR);

	test_map_base = (char *)

	    mmap(0, 0xd000, PROT_READ | PROT_WRITE, MAP_SHARED, fd,

		 0);

//	test_virt_base = test_map_base + (TargetAddr & MAP_MASK);

//	LOGD("virtual base at %p (phys=0x%X)\n", test_virt_base, [[TargetAddr]]);

	LOGD(" -- htc-acoustic memory write -- \n");

          for (len = 0; len < 0xd000; len++)

		{

		  read(fdd, test_map_base, sizeof(char) );

		  test_map_base++;

		}

	munmap(test_map_base, 0xd000);

	close(fdd);

	close(fd);

}

void acoustic_done(void)

{

     int fd;

	       fd = open("/dev/htc-acoustic",O_RDWR);

               if (fd < 0) {

	            LOGE("Cannot open htc-acoustic device");

	            close(fd);

	            return;

               }

       ioctl(fd,ACOUSTIC_ARM11_DONE, NULL);

       close(fd);

}

</pre>

Now replace:

<pre>

    set_acoustic_parameters = (int (*)(void))::dlsym(acoustic, "set_acoustic_parameters");

    if ((*set_acoustic_parameters) == 0 ) {

        LOGE("Could not open set_acoustic_parameters()");

        return;

    }

    int rc = set_acoustic_parameters();

    if (rc < 0) {

        LOGE("Could not set acoustic parameters to share memory: %d", rc);

//        return;

    }

</pre>

with:

<pre>

acoustic_mmap();

acoustic_done();

</pre>

Build system.img: @make -j9 systemimage@ and flash it to your device. Now '''audioacoustic should work''' but it's not a clean way to make it work: the clean way is to parse the CSV file and load it to MSM shared memory with free code. If it does not work, then your device is definitely not working like the Dream and you'll have to find another way to make it work. 

Replace the hardware/msm7k/ folder by the replicant one. The next step is to find the right addresses to write the tables in MSM shared memory. To find this out, you have to read the dump and understand where each table begins. So first, you have to hexdump the dump:

@hexdump -C dump > dump.txt@. This will create dump.txt, containing the hexedacimal values of dump as text. So now you should be able to understand where each table begins. As an example, here's how it was done with the dream values: consider the following as the beginning of the dump.txt file: 

<pre>

00000000  35 71 36 61 37 00 38 00  39 03 3a 00 3b 00 3c 00  |5q6a7.8.9.:.;.<.|

00000010  3d 00 3e 00 3f 00 40 00  41 1c 42 00 43 00 44 00  |=.>.?.@.A.B.C.D.|

00000020  45 00 46 00 47 00 48 00  49 00 4a 01 4b 00 4c 00  |E.F.G.H.I.J.K.L.|

00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

00000080  35 71 36 61 37 00 38 00  39 03 3a 00 3b 00 3c 00  |5q6a7.8.9.:.;.<.|

00000090  3d 00 3e 00 3f 00 40 00  41 1c 42 00 43 00 44 00  |=.>.?.@.A.B.C.D.|

000000a0  45 00 46 00 47 00 48 00  49 00 4a 01 4b 00 4c 00  |E.F.G.H.I.J.K.L.|

000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

</pre>

it's the 2 first elements of the table we want to find the address (which will be 00000000, the beginning of the table). Now read [[AudioPara]]4.csv. On the dream, you can read:

<pre>

A0,HTC_VOC_CODEC_EARCUPLE_VOICE,35,71,36,61,37,0,38,0,39,3,3A,0,3B,0,3C,0,3D,0,3E,0,3F,0,40,0,41,1C,42,0,43,0,44,0,45,0,46,0,47,0,48,0,49,0,4A,1,4B,0,4C,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

A1,HTC_VOC_CODEC_EARCUPLE_MIDI,35,71,36,61,37,0,38,0,39,3,3A,0,3B,0,3C,0,3D,0,3E,0,3F,0,40,0,41,1C,42,0,43,0,44,0,45,0,46,0,47,0,48,0,49,0,4A,1,4B,0,4C,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

</pre>

you can see that @35 71 36 61 37 00 38 00  39 03 3a 00 3b 00 3c 00@ is the same as @35,71,36,61,37,0,38,0,39,3,3A,0,3B,0,3C,0@, so @35 71 36 61 37 00 38 00  39 03 3a 00 3b 00 3c 00@ is the beginning of the first element of table A. So table A starts at 0. 

Now if you read the [[ParseAudioParaLine]] function from [[AudioAcoustic]].cpp (on the already existing free audio acoustic code), you can see:

<pre>

        case 'A':

[…]

            while ( (token = strtok(NULL, ",")) ) {

                Audio_Path_Table[table_num].array[field_count++] = strtol(token, &ps, 16);

            };

            break;

</pre>

So "A" is for the Audio_Path_Table table. 

Now you have to do the same work for every table. You can see that another tables begins when the table-specific characters change e.g.:

<pre>

00001780  35 00 36 00 37 ff 38 00  39 00 3a 00 3b 00 3c c4  |5.6.7.8.9.:.;.<.|

00001790  3d c4 3e 08 3f 80 40 05  41 00 42 00 43 00 44 00  |=.>.?.@.A.B.C.D.|

000017a0  45 00 46 00 47 00 48 00  49 00 4a 00 4b 00 4c 00  |E.F.G.H.I.J.K.L.|

000017b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

00001800  00 00 00 40 13 20 00 00  b2 7f fd 23 00 00 33 2d  |...@. .....#..3-|

00001810  00 00 80 0c 9a ff 80 1d  33 f3 ec 01 ee ff 0a 20  |........3...... |

00001820  65 7f 00 00 00 ed 00 00  00 00 d9 3f 00 00 80 0c  |e..........?....|

00001830  9a ff 0c 1b 33 f3 ec 01  ee ff 0a 20 65 7f ff 7f  |....3...... e...|

00001840  00 08 ff 7f 9f 14 00 00  14 00 00 08 00 20 00 20  |............. . |

00001850  fa 00 46 00 02 00 ff 02  40 00 20 00 50 46 40 00  |..F.....@. .PF@.|

00001860  a0 41 00 08 63 00 ff 4d  ff 4d 02 00 00 3f d0 07  |.A..c..M.M...?..|

00001870  00 00 00 00 00 01 00 01  00 02 50 00 00 03 50 01  |..........P...P.|

00001880  64 00 a8 1c c2 01 e0 2e  a0 0f ff ff 00 00 00 00  |d...............|

00001890  00 00 00 00 00 00 00 00  00 40 00 00 00 00 00 00  |.........@......|

000018a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

</pre>

You can see that a new table begins at 0x1800.

Note that some tables may not start at easy-to-find addresses such as 0x1800 but may start at in the middle of an hexdump line (so it makes the task even harder).

When you have found all the correct addresses for every table in your CSV file, you should check that your tables have the same size than the tables you got from the dump. If it's not, adjust the tables defined in [[AudioAcoustic]].h and the tables defined at the top of [[AudioAcoustic]].cpp. 

When all that stuff is ok, it's possible that there is a necessary footer to make it work. On the Dream, it is:

<pre>

0000c8e0  78 56 34 12 00 00 00 00  00 00 00 00 00 00 00 00  |xV4.............|

</pre>

(present at the end of the dump file).

Now that you found out the size of the memory map, the address of each table, adjusted the size of the tables and found the footer, it's time to put the remaining infos on the free code.

Modify with the values you found out, on the file hardware/msm7k/libaudio/AudioAcoustic.cpp:

<pre>

static int mmap_size = 0xd000;

static int mmap_address_audio_path_table = 0x0;

static int mmap_address_audio_path_uplink_table = 0xc00;

static int mmap_address_phone_acoustic_table = 0x1800;

static int mmap_address_bt_phone_acoustic_table = 0x4a00;

static int mmap_address_htc_voc_cal_codec_table_table = 0xc700;

static int mmap_address_htc_acoustic_end = 0xc8e0;

</pre>

and adapt the array sizes both on the top of [[AudioAcoustic]].cpp and [[AudioAcoustic]].h (if you didn't do it already).

Then build an image (make -j9 systemimage) and it should work. If it does not, please check that you successfully passed all the required steps. 

But the fact is that you replaced Dream values with the correct values for your device, so it will break audio acoustic for Dream.

The solution would be to write a set_device_configuration() which selects the good values for the device we build replciant for and the appropriated tables. 

Nothing like that has been written yet since replicant [[AudioAcoustic]] hasn't been ported to any other device yet. Please notify replicant developers to write such a function (or do it yourself) before you send the code.

h3. GPS

Two GPS libraries exist:

* libgps

* libloc_api

Both provide the same functionalities at the application level.

Choose the one that is supported by your device or that has support for a device close to your device.

h4. libgps

For adding support to libgps you need to enable it like in "this commit":http://gitorious.org/replicant/android_device_htc_dream_sapphire/commit/153ab7e8fcf6bfc294b200d60a6f01feb5bb571a:

add the following(or modify if it's already there but holds another value) in device/htc/dream_sapphire/BoardConfig.mk (replace dream_saphire by your device code) :

<pre>

BOARD_HAVE_GPS_HARDWARE := true

BOARD_GPS_LIBRARIES := libhardware

</pre>

I'm not sure if the "BOARD_HAVE_GPS_HARDWARE := true" is really needed.

If your device is different from the htc dream you may have to modify the GPS library code to match your device,

Here's the adaptation made for the htc dream:

<pre>

hardware/libhardware_legacy/gps$ diff -u ../../../../repos_external/phh_libhardware_legacy/gps/gps-rpc.c ./gps-rpc.c 

--- ../../../../repos_external/phh_libhardware_legacy/gps/gps-rpc.c	2010-08-15 11:35:03.210095153 +0200

+++ ./gps-rpc.c	2011-01-06 16:46:45.417685002 +0100

@@ -464,8 +464,8 @@

 }

 int init_gps6125() {

-	struct CLIENT *clnt=clnt_create(NULL, 0x3000005B, 0, NULL);

-	struct CLIENT *clnt_atl=clnt_create(NULL, 0x3000001D, 0, NULL);

+	struct CLIENT *clnt=clnt_create(NULL, 0x3000005B, 0x90380d3d, NULL);

+	struct CLIENT *clnt_atl=clnt_create(NULL, 0x3000001D, 0x51c92bd8, NULL);

 	int i;

 	_clnt=clnt;

 	SVCXPRT *svc=svcrtr_create();

@@ -538,33 +538,21 @@

 int init_gps_rpc() {

-	int fd=open("/sys/class/htc_hw/amss", O_RDONLY);

-	char bufr32;

-	bzero(buf, 32);

-	read(fd, buf, 32);

-	if(strncmp(buf, "6125", 4)==0)

-		amss=A6125;

-	else if((strncmp(buf, "5225", 4)==0) || (strncmp(buf, "6150", 4)==0))

-		amss=A5225;

-	else

-		amss=A6125; //Fallback to 6125 ATM

-	if(amss==A6125)

-		init_gps6125();

-	else if(amss==A5225)

-		init_gps5225();

+	amss=A6125;

+	init_gps6125();

 	return 0;

 }

 void gps_get_position() {

 	int i;

-	for(i=5;i;--i) if(!can_send) sleep(1);//Time out of 5 seconds on can_send

+	for(i=3;i;--i) if(!can_send) sleep(1);//Time out of 5 seconds on can_send

 	can_send=0;

 	pdsm_get_position(_clnt, 0, 0, 1, 1, 1, 0x3B9AC9FF, 1, 0,0,0,0,0, 0,0,0,0,0, 0,0,0,0,0, 0,0,1,32,2,client_IDsr2);

 }

 void exit_gps_rpc() {

-	if(amss==A6125)

-		pdsm_client_end_session(_clnt, 0, 2);

+	//if(amss==A6125)

+	//	pdsm_client_end_session(_clnt, 0, 2);

 	//5225 doesn't seem to like end_session ?

 	//Bah it ends session on itself after 10seconds.

 }

</pre>

so let's go step by steps on that diff:

First we see that:

<pre>

+	struct CLIENT *clnt=clnt_create(NULL, 0x3000005B, 0x90380d3d, NULL);

+	struct CLIENT *clnt_atl=clnt_create(NULL, 0x3000001D, 0x51c92bd8, NULL);

</pre>

This corresponds to some devices nodes:

<pre>

# ls -l /dev/oncrpc

crw-rw----    1 radio    system    253,   0 Jan  6 16:43 00000000:0

crw-rw----    1 radio    system    253,  11 Jan  6 16:43 30000000:5a10cf88

crw-rw----    1 radio    system    253,   9 Jan  6 16:43 30000002:aa2b1a44

crw-rw----    1 radio    system    253,   4 Jan  6 16:43 30000003:94103dec

crw-rw----    1 radio    system    253,  30 Jan  6 16:43 3000000a:71d1094b

crw-rw----    1 radio    system    253,  28 Jan  6 16:43 3000000e:2bf06595

crw-rw----    1 radio    system    253,  26 Jan  6 16:43 3000000f:46d257e5

crw-rw----    1 radio    system    253,  23 Jan  6 16:43 30000013:e94e8f0c

crw-rw----    1 radio    system    253,  22 Jan  6 16:43 30000014:7cfcd2c6

crw-rw----    1 radio    system    253,  21 Jan  6 16:43 30000016:c713bd79

crw-rw----    1 radio    system    253,  19 Jan  6 16:43 30000019:acb4a896

crw-rw----    1 radio    system    253,  18 Jan  6 16:43 3000001b:97d7b24a

crw-rw----    1 radio    system    253,  12 Jan  6 16:43 3000001d:51c92bd8

crw-rw----    1 radio    system    253,   8 Jan  6 16:43 30000021:f330a24e

crw-rw----    1 radio    system    253,  14 Jan  6 16:43 3000003c:03d4377c

crw-rw----    1 radio    system    253,  29 Jan  6 16:43 30000048:0da5b528

crw-rw----    1 radio    system    253,  17 Jan  6 16:43 30000059:00000000

crw-rw----    1 radio    system    253,  16 Jan  6 16:43 3000005a:00000000

crw-rw----    1 radio    system    253,  13 Jan  6 16:43 3000005b:90380d3d

crw-rw----    1 radio    system    253,   7 Jan  6 16:43 3000005f:95d1d9f5

crw-rw----    1 radio    system    253,   5 Jan  6 16:43 30000060:bcfb5d63

crw-rw----    1 radio    system    253,   2 Jan  6 16:43 30000061:fb837d0b

crw-rw----    1 radio    system    253,  31 Jan  6 16:43 30000066:1f4b343e

crw-rw----    1 radio    system    253,  27 Jan  6 16:43 3000006b:0aabc7a4

crw-rw----    1 radio    system    253,  25 Jan  6 16:43 3000006c:00000000

crw-rw----    1 radio    system    253,  20 Jan  6 16:43 30000075:f708938d

crw-rw----    1 radio    system    253,  15 Jan  6 16:43 30000079:00000000

crw-rw----    1 radio    system    253,   1 Jan  6 16:43 30000081:ccc5b439

crw-rw----    1 radio    system    253,  24 Jan  6 16:43 3000fe00:00000000

crw-rw----    1 radio    system    253,  10 Jan  6 16:43 3000fffe:00000000

crw-rw----    1 radio    system    253,   6 Jan  6 16:43 30100001:00000000

crw-rw----    1 radio    system    253,   3 Jan  6 16:43 30100002:00000000

</pre>

Theses 2 lines should ring a bell:

<pre>

crw-rw----    1 radio    system    253,  13 Jan  6 16:43 3000005b:90380d3d

crw-rw----    1 radio    system    253,  12 Jan  6 16:43 3000001d:51c92bd8

</pre>

Next there is that line:

<pre>

+	for(i=3;i;--i) if(!can_send) sleep(1);//Time out of 5 seconds on can_send

</pre>

This is the time between 2 requests, if you put it too low it can reboot your phone(it will crashes and reboot)

h4. libloc_api

For adding support for libloc_api you need to modify the BOARD_GPS_LIBRARIES variable

"That repository":https://github.com/CyanogenMod/android_hardware_qcom_gps should have newer devices support(like in AOSP) and older too(like rmcc's commits)

h4. testing

<pre>

cd hardware/libhardware_legacy/tests/gpstest/

mm

</pre>

gives you a gpstest binary, copy it to the device and run it, it'll tell you if it has a fix

h4. Note on the GPS

Note that messing with GPS can reboot(that is to say your phone crashes and reboots because of that) your phone on certain devices(like the htc dream or the nexus one).

The GPS is attached to the modem on the htc dream and the nexus one.

The only way to request a fix or to activate it is trough a rpc mecanism that is between the modem and the CPU that runs Android.

That RPC mecanism uses shared memory between the modem and the CPU that runs Android.

On the htcdream and the nexusone a serial line is emulated on top of the RPC mecanism: the serial lines can be accesed at /dev/smd0 for the modem(AT commands) and /dev/smd27 for the GPS NMEA.

So compatibility with applications that understand NMEA is garanteed.

Note that the GPS parsing library doesn't require to use NMEA, it could also uses the RPC directly(to be verified)

h3. Sensors

Devices with an hardware keyboard slide can rotate with the slide of the keyboard, so accelerometers are not strictly necessary. Examples of such device include the HTC dream.

Other devices lack that hardware keyboard, and so the only way to rotate is trough theses accelerometers. Examples of such device include the nexus one.

The nexusone has akmd.free which is the free implementation of akmd, the sensor daemon(which handle rotation)

h4. akmd.free

akmd.free is located in:

<pre>

hardware/akmd_free

</pre>

it has currently(at the time of writing) support for akm8973+bma150 based sensors.

akmd.free was made specifically for the htc hero by its authors.

The device supported include the nexus one(tested) and the HTC hero(not tested,not activated).

In order to activate the support for it you must add that in your [[BoardConfig]].mk

<pre>

BUILD_AKMD := true

</pre>

If you need to add support for other akm sensors  you could modify hardware/akmd_free/jni/Android.mk, for instance the nexusone had an issue with rotation beeing done in the reverse sense, so I did that:

<pre>

+#ifdef TARGET_DEVICE_NEXUSONE

+    abuf[index] = Vector(-bma150_datar0, -bma150_datar1, bma150_datar2);

+#else

     abuf[index] = Vector(bma150_datar0, -bma150_datar1, bma150_datar2);

+#endif

</pre>

And that:

<pre>

ifeq ($(TARGET_DEVICE),passion)

  LOCAL_CFLAGS += -DTARGET_DEVICE_NEXUSONE

endif

</pre>

h3. Slowness issues

If the device is too slow without non-free libs, there can still be some workarounds:

* Adding debug.sf.hw=0 in the proprieties: in a makefile on the device files, add:

<pre>

PRODUCT_PROPERTY_OVERRIDES += debug.sf.hw=0

</pre>

* Use a patched gralloc: the "Code Aurora":https://www.codeaurora.org/gitweb/quic/la/ had a fix for a nasty Nexus One graphics bug on the @froyo_almond@ branch.

* Use TARGET_LIBAGL_USE_GRALLOC_COPYBITS with libagl: if your device uses gralloc+copybits, you can try a fix that improved the speed on Nexus One: in a makefile on the device files, add:

<pre>

TARGET_LIBAGL_USE_GRALLOC_COPYBITS := true

</pre>

The commits with these fixes for Nexus One are:

* https://gitorious.org/replicant/android_device_htc_passion/commit/86aeb1822a90b71e2cbb1af71200e759d98f4993

* https://gitorious.org/replicant/android_hardware_msm7k/commit/d2d79391f10789ed9d2f5dd818aac3b23c48d69e

h2. Re-using source code

The previous source code re-used some public source code that was licensed under the Apache 2.0 license.

The ril will also re-use some public source code licensed under Apache 2.0.

That is the advised way to do it as it save some time and is easier to do, however proper credit must be attributed, at least in the commit message.

It is even advised to look at the public apache 2.0 source code of other rils libraries or components of android.

h3. Ril

* vilvord ril

* openmoko (android on freerunner) ril

h2. Source organization and commit access

Until now we made some changes in the tree, but we want the changes to land upstream in replicant.

For instance let's say we modified only the ril path like in the ril section in 

<pre>

device/htc/dream_sapphire/full_dream_sapphire.mk 

</pre>

first we save our modifications:

<pre>

cd device/htc/dream_sapphire/

git diff > git_diff.patch

</pre>

then we find where is the root of the git repository we are in:

<pre>

cd replicant-2.2 #top replicant directory where everything is in

cd .repo

cat manifest.xml

</pre>

and we find that:

<pre>

  <project path="device/htc/buzz" name="CyanogenMod/android_device_htc_buzz" remote="github" />

</pre>

so...now our repository is in device/htc/buzz

We will now look where the source repository is:

<pre>

cd device/htc/buzz

cd .git

cat config

</pre>

We find that:

<pre>

	url = git://github.com/CyanogenMod/android_device_htc_buzz.git

</pre>

Then create a directory, not under the replicant-2.2 directory that will contain your repositories:

<pre>

mkdir repo

cd repo

</pre>

and clone the source:

<pre>

git clone git://github.com/CyanogenMod/android_device_htc_buzz.git

cd android_device_htc_buzz

</pre>

apply the previous patch:

<pre>

git apply path/to/git_diff.patch

</pre>

commit locally the result:

<pre>

git commit -s

</pre>

Note that the commit message should have the following format:

The first line should be a summary

Followed by a linebreak

And then the details explaining the commit

If you made an error writing the commit message do

<pre>

git commit --amend

</pre>

TODO: complete for sending the git patch(git format-patch -1,git send-email)

h4. Pushing to replicant

TODO: git remote add+git push