device tree ish

To back up my post , here is what cyanogen mod had to say


Helpful Tip


Collect information about your device

Before you begin your port, you will want to collect as much information about your device as you can. Go to wikipedia and identify the product name, code name, architecture, memory size, internal storage size, and platform architecture. Put this information in a file for easy retrieval. Try to learn as much about the device, including any similarities it may have to other devices.

step 2

Look at the device's current /system/build.prop

Assuming the device is already running a version of Android, there should be a file, /system/build.prop, on the device which may contain useful information that will come into play as you do your port. This file contains definitions for various parameters and settings used by Android.

So, if you have previously installed adb onto your computer, you can use the following command to pull this file to your computer:

adb pull /system/build.prop

If you receive an error relating to permissions, the device may need to be rooted to gain access to this file. However, there are other ways to locate this file. For example, it may be included in any stock firmware "upgrade" package online.

Once you have the file...
Write down the value of the ro.product.manufacturer parameter. This will be your vendor name. The [vendor] is the name of the manufacturer/vendor of the device. CM has established naming conventions for most major vendors, such as samsung, htc, lge, etc. Note that in these directory names, the vendor is always lowercase and contains no spaces.
Write down the value of the ro.product.device parameter. This will be your device codename. The [codename] corresponds to the project code name of the device itself. This is almost never the sales name of the device. If you have built CM before (and again, you better have!), you should be familiar with the concept of a code name for each device. Like the vendor name, the codename is always lowercase and contains no spaces.

Note:

Sometimes a device is identified in other parameters such as ro.product.board

Keep the build.prop file handy, as you may refer to it later.

step 3

Examine boot.img and recovery.img

As stated, when doing your port, you may wish to use an existing pre-built kernel that you know works instead of building one from source code. Depending on your device, you may need to extract this kernel file from the device. The kernel may exist as a single file (as it does on many OMAP devices) or may be wrapped up along with the ramdisk in a boot or recovery partition.

Similarly, the contents of the stock ramdisk may be extremely helpful and can often be extracted and reviewed. It may be the case that a device requires specific files from the stock ramdisk in order to boot properly, load a module, etc. In most cases you can view files in the ramdisk from the device itself, but it you may prefer to look at the full directory.

step 4

You can frequently extract the boot and recovery images (to a file you name boot.img and recovery.img) on a rooted Android device using dd. Or, if you have access to an update .zip file from the vendor, you can often find those files within.

Collect any available existing source code

The manufacturer or vender of any device using Android will minimally need to make the source code available for all GPL components upon request, including (and especially) the kernel. You definitely want to request a copy of the kernel source and keep it handy.

Determine the partition scheme

It is important to ascertain the partition scheme of the device. The recovery image you build will need this information to know where to find the various Android directories. Particularly, you want to know which partitions are assigned to /system, /data, /cache, and /sdcard.

You want to know which partitions exist, on what device, how they are mounted, as well as the size of the partitions. This information may be transferred later to the BoardConfig.mk file in your /vendor directory.

If you're lucky, a recovery.fstab file can be located in a recovery.img file, speeding up the process of figuring out what goes where. Also, the init.[codename].rc file in the ramdisk may have the information. Look for the lines near the top where the partitions are mounted.

Also, the command:

$ cat /proc/partitions

from a running device can also help you identify the partitions. Also see /proc/emmc, /proc/mounts or /proc/mtd. You may also get some information from the command mount (run as root).

Also check /cache/recovery.log or /tmp/recovery.log.

Finally, if you have source code to the bootloader (such as the u-boot used by many OMAP-based devices), you will likely find the information there as well.


step 5

Set up three new directories

Now that you've hopefully gathered enough information to complete your config, it's time to generate the folders for your device configuration, located in the following directories, relative to the code source directory.

1. device/[vendor]/[codename]/ -- this is where the installation files specific to your device will go. The device/ directory contain 99-100% of the configuration settings and other code for particular devices. You'll get to know this directory pretty well. As mentioned, when starting the folder for this device, it may be a good idea to adapt a directory for an existing device that is architecturally similar to the one you wish to port. Look for a device that is based on the same platform, for example.

2. vendor/[vendor]/[codename]/ -- The vendor/ directory contains proprietary, binary "blobs" that are backed up from the original device (or provided by the vendor, such as in the case of Google Nexus devices and some TI graphics blobs).

3. kernel/[vendor]/[codename]/ -- the kernel source goes here. When you first start your porting effort, you may wish to simplify things by using a pre-built kernel (such as the one that came with the stock installation) rather than building the kernel from scratch. The trick to that will be extracting the kernel out of the stock system from whatever format it may be in, and then re-packaging it, along with a new ramdisk, into a form that your device can use. This can vary from device-to-device, so it may again be helpful to look at similar devices to yours that use a similar architecture. Building the kernel from source is not strictly necessary for every device, but in the spirit of open source, it is the preferred practice for CyanogenMod. See here for a detailed discussion about how CyanogenMod builds the kernel source from scratch.

There are at least three methods to generate these directories:

(the rest of this tutorial is here) ://wiki.cyanogenmod.org/w/Doc:_porting_intro

here is some good info for ninjainpajamas about github
://xda-university.com/as-a-developer/porting-aosp-roms-using-source-code

I uploaded a nice .pdf check it out .. just add http before ":"
://www48.zippyshare.com/v/89868576/file.html