DeprecatedPortingGuideS5PC110 » History » Version 10
Paul Kocialkowski, 12/23/2012 11:41 AM
1 | 1 | Paul Kocialkowski | h1. PortingGuideS5PC110 |
---|---|---|---|
2 | |||
3 | *This guide assumes your phone has a S5PC110/Exynos 3110 SoC* |
||
4 | |||
5 | 3 | Paul Kocialkowski | h2. Prerequisites |
6 | 1 | Paul Kocialkowski | |
7 | 3 | Paul Kocialkowski | Before porting your device to Replicant, you must make sure it complies with the following: |
8 | * Already supported by CyanogenMod (or, worst-case scenario, by a non-official CyanogenMod port) |
||
9 | * CyanogenMod support for this device is available for one of Replicant versions (pick the latest) |
||
10 | * The phone is GSM: Replicant doesn't support CDMA phones yet |
||
11 | * It is likely to be usable without blobs nor firmwares and with Replicant replacements |
||
12 | 1 | Paul Kocialkowski | |
13 | 3 | Paul Kocialkowski | h2. Investigating the phone hardware |
14 | 1 | Paul Kocialkowski | |
15 | 3 | Paul Kocialkowski | Before doing anything, you will need to know the codename of the device. You can find it out on "CyanogenMod Wiki":http://wiki.cyanogenmod.org/ or on "CyanogenMod download page":http://get.cm/. |
16 | For instance, the "Nexus S":http://wiki.cyanogenmod.org/wiki/Nexus_S codename is: @crespo@. |
||
17 | 1 | Paul Kocialkowski | |
18 | 3 | Paul Kocialkowski | First thing to consider before starting a port, when all of the above is assumed, is to see how many non-free components are required by CyanogenMod. |
19 | The easiest way to do this is to spot the device repository in "CyanogenMod repos":https://github.com/CyanogenMod/ and look for the @extract-files.sh@ or @proprietary-blobs.txt@ file. |
||
20 | For instance, the list of non-free components for the "Nexus S":https://github.com/CyanogenMod/android_device_samsung_crespo is "extract-files.sh":https://github.com/CyanogenMod/android_device_samsung_crespo/blob/ics/extract-files.sh |
||
21 | |||
22 | From that list, spot what is related to what hardware component (audio, camera, sensors, gps, modem, etc): that gives an idea of the amount of work required to add support for the phone. |
||
23 | |||
24 | During the port, you might need to find precise infos about the hardware that is in the phone. A good to do this is by looking at the kernel defconfig for the device, another way is to download the Service Manual for the device. |
||
25 | |||
26 | h2. Getting everything ready |
||
27 | |||
28 | In order to prepare everything for the Replicant port: |
||
29 | * Install CyanogenMod on the phone |
||
30 | * Install the [[BuildDependencies]] |
||
31 | * Get the sources: [[GettingReplicantSources]] |
||
32 | * Read Replicant developer guide: [[DeveloperGuide]] |
||
33 | * Learn how to do debug: [[GettingLogs]] [[GDBDebugging]] |
||
34 | |||
35 | 8 | Paul Kocialkowski | h2. Cloning the device files |
36 | |||
37 | Once your Replicant tree is ready, you can start by adding the necessary repos for your device. |
||
38 | That means cloning the necessary repos in the right place. These repos are: |
||
39 | 10 | Paul Kocialkowski | * A *device-specific repo*. On CyanogenMod, it is usually called: @android_device_vendor_device@. |
40 | * Sometimes one or more *common repo(s)*, usually called: @android_device_vendor_devices-common@. |
||
41 | 1 | Paul Kocialkowski | Some devices don't need any common repo, but some do. |
42 | 10 | Paul Kocialkowski | * A *kernel repo*. On CyanogenMod, it is usually called: @android_kernel_samsung_devices@. |
43 | 8 | Paul Kocialkowski | The kernel repo can be shared across a family of devices (for instance, on kernel repo for Samsung Exynos, one for Samsung OMAP, etc). |
44 | 10 | Paul Kocialkowski | If there are different branches in the kernel repo, be sure to use the one that will match userspace: if you are porting to ICS, take the branch called @ics@ or ask the people who know which branch to use. |
45 | Generally speaking, the following kernel versions match the given userspaces: |
||
46 | 1 | Paul Kocialkowski | |
47 | 10 | Paul Kocialkowski | | *Android version* | *CyanogenMod version* | *Kernel version* | |
48 | | Android 2.3 | CM 7.x | 2.6.35 | |
||
49 | | Android 4.0 | CM 9.x | 3.0.8 | |
||
50 | | Android 4.1 | CM 10 | 3.0.31 | |
||
51 | | Android 4.2 | CM 10.1 | 3.4 | |
||
52 | |||
53 | 9 | Paul Kocialkowski | Clone these repos in the correct locations and remove the prefix (e.g. @android_device_samsung_crespo@ must be cloned in @device/samsung/@ and renamed to @crespo@). |
54 | |||
55 | 8 | Paul Kocialkowski | h3. Creating the kernel repo |
56 | |||
57 | If the kernel repo is nowhere to be found, you'll need to get the kernel source directly from the vendor, especially if your device is supported by a 3rd party CyanogenMod fork. |
||
58 | Keep in mind that the Linux kernel is GPLv2, so vendors have the legal obligation to release the modified kernel sources as soon as they sell you the device. |
||
59 | That means the kernel sources will be available online. Here are some websites where such releases are done: |
||
60 | * "Samsung Open Source Release Center":http://opensource.samsung.com/ |
||
61 | For Samsung kernels. Search the device codename (e.g. I9000) and download the package called "Opensource Update" (e.g. GT-I9000_Opensource_GB_Update2.zip). |
||
62 | This will hold a kernel archive with all the sources and instructions on how to build it and which defconfig to use. |
||
63 | |||
64 | Once you have the kernel sources, read the instructions to find out which defconfig to use. |
||
65 | |||
66 | Since manufacturers usually don't release the git history along with the files, you'll need to recreate a git repo: |
||
67 | * Clone the mainline kernel in the same version as the Makefile from the sources you just obtained |
||
68 | * Remove the cloned files *except the .git directory* |
||
69 | * Move the manufacturer kernel tree at the place of the files you just removed |
||
70 | * Add all the files in git (@git add -A@) and commit (@git commit@) with a message explaining what you just imported (e.g. "GT-I9000 GB Opensource Update 2") |
||
71 | |||
72 | Now that you have a git repo, you can move it to the Replicant code tree, under the name: @kernel/vendor/devices@ (e.g. @kernel/samsung/aries@). |
||
73 | Make sure to make the @devices@ name match the @devices@ in @android_device_vendor_devices-common@ if the kernel is shared across these devices or to match the @device@ in @android_device_vendor_device@. |
||
74 | |||
75 | 9 | Paul Kocialkowski | h3. Adding the device to the build targets |
76 | |||
77 | Now that the repos are cloned, you need to modify some makefiles to cope with Replicant paths. |
||
78 | In the device repository (@device/vendor/device@), modify the file called @cm.mk@ and replace the @vendor/cm/@ occurrences by @vendor/replicant/@. Other makefiles may need that as well (in any case, build will fail very early if you missed one). In that same @cm.mk@ file, change the PRODUCT_NAME variable by repalcing the @cm@ prefix with @replicant@ (e.g. change PRODUCT_NAME := cm_crespo to PRODUCT_NAME := replicant_crespo). |
||
79 | |||
80 | Now that your device files are ready, you can declare a new build target: these are held in @vendor/replicant/jenkins-build-targets@. |
||
81 | Modify that file and add a line (at the end) with the PRODUCT_NAME you set and the @-eng@ suffix (e.g. @replicant_crespo-eng@). |
||
82 | |||
83 | From now on, everything should be ready to start a build. To check for errors or missed occurrences, start a terminal in the Replicant tree root and lunch: |
||
84 | <pre> |
||
85 | source build/envsetup.sh |
||
86 | lunch replicant_device-eng |
||
87 | </pre> |
||
88 | |||
89 | Adapt replicant_device-eng from what you added to the @jenkins-build-target@ (e.g. @replicant_crespo-eng@). |
||
90 | If an error occurs, it will explicitly report it and you'll need to fix it before doing anything. |
||
91 | If everything works correctly, you should see something like: |
||
92 | <pre> |
||
93 | ============================================ |
||
94 | PLATFORM_VERSION_CODENAME=REL |
||
95 | PLATFORM_VERSION=4.0.4 |
||
96 | TARGET_PRODUCT=replicant_crespo |
||
97 | TARGET_BUILD_VARIANT=eng |
||
98 | TARGET_BUILD_TYPE=release |
||
99 | TARGET_BUILD_APPS= |
||
100 | TARGET_ARCH=arm |
||
101 | TARGET_ARCH_VARIANT=armv7-a |
||
102 | HOST_ARCH=x86 |
||
103 | HOST_OS=linux |
||
104 | HOST_BUILD_TYPE=release |
||
105 | BUILD_ID=IMM76L |
||
106 | ============================================ |
||
107 | 1 | Paul Kocialkowski | </pre> |
108 | |||
109 | h2. Building the kernel |
||
110 | 10 | Paul Kocialkowski | |
111 | Once the devices repos are in place and the build target is configured, you are now able to start building things. |
||
112 | |||
113 | 8 | Paul Kocialkowski | |
114 | 9 | Paul Kocialkowski | Now that the devices repos are in place, |
115 | 8 | Paul Kocialkowski | |
116 | For doing that, you need to sport where the kernel source is held. CyanogenMod |
||
117 | |||
118 | 1 | Paul Kocialkowski | h2. Get the source and build a kernel image |
119 | |||
120 | * adding the 3rd party repos if any |
||
121 | * add kernel: where the find the kernels? |
||
122 | - official feeds |
||
123 | - the ones on GIT (teamhacksung, better ask CM people) |
||
124 | - 3rd party projects |
||
125 | * add kernel to product files on vendor/replicant |
||
126 | 2 | Paul Kocialkowski | |
127 | * change ro.modversion on product vendor file |
||
128 | 4 | Paul Kocialkowski | |
129 | 6 | Denis 'GNUtoo' Carikli | h2. Various hardware and software fixes to get things working. |
130 | 1 | Paul Kocialkowski | |
131 | 6 | Denis 'GNUtoo' Carikli | h3. To get software video decoding (OMX stuff): |
132 | 7 | Denis 'GNUtoo' Carikli | |
133 | 4 | Paul Kocialkowski | * remove OMX libs for hardware video decoding |
134 | 1 | Paul Kocialkowski | * remove libstagefrighthw.so |
135 | 5 | Denis 'GNUtoo' Carikli | like that: http://gitorious.org/replicant/device_samsung_crespo/commit/c8edb6539977c8820d665691d53c33892cfa4fdd |