"Turn" Android MSM8974 on the Devicetree profile----good

Original URL: http://blog.csdn.net/dongwuming/article/details/12784213

Introduction

The main function is not to hardcode the device information in the code, but to describe it with a special file. The device node of the whole system will form a tree, and the device node can set properties. Official website in http://www.devicetree.org. Please refer to Http://www.devicetree.org/Device_Tree_Usage for getting Started guide. Some conditions on Linux, please refer to "kernel/document/devicetree/", wherein "bindings" sub-directory describes the various devices Devicetree description method, each manufacturer of various types of equipment description method may be different.

MSM8974 on Devicetree Introduction

The device description source file is placed under "kernel/arch/arm/boot/dts/" with the suffix ". DTS" or ". DTSi", the general ". DTSi" is contained by other files, and only the ". DTS" file is compiled with DTC. Build will use the "DTC" command to compile the required device profile into a ". DtB" file and place it somewhere in the bootimage. The implementation of the resolution processing of the device description is mainly in the "kernel/drivers/of/" directory, you need to configure "config_of". During the start-up process, bootloader (the default is BOOTABLE/BOOTLOADER/LK) chooses the appropriate devicetree to load memory according to the machine hardware information, and transmits the relevant information such as the address to kernel. Kernel, the device is created based on the information that is passed in.

version declarations and other files included

The general ". DTS" file will be versioned first, as in the first line below. ". DTS" or ". DTSi" files may also contain other ". DTSi" files, such as the following 3/4 lines.

/dts-v1/;/include/"Msm8974-v2.2.dtsi"/include/"Msm8974-mtp.dtsi"

about the use of the take address symbol

If you often encounter similar to the following wording. Did not find the relevant documentation (see Source to understand also very laborious). The function should be to add a description of the previously defined device ("SOC" in the example).

&SOC {[email protected] {compatible = "Qcom,android-usb"; reg = <0xfe8050c8 0xc8>;qcom, Android-usb-swfi-latency = <1>;}; ......};

which files are programmed into binary images

There are two ways of using DT. The first can contain multiple DTB, programmed into dt.img, and put into boot.img. The second type contains only one DTB, which is appended directly to the kernelimage and placed in boot.img.
DTC compilation is defined in Kernel/androidkernel.mk. Using the definition "dts_names" variable, each of its entry (recorded as "dts_name" variable, the following $ $arch) may have the arch and Rev two parts, and. config related to the configuration, use the following method to find out.

while (<>) {$ $a = $$1 If/config_arch_ (?: msm| qsd| MPQ) [a-za-z0-9]+] =y/;$ $r = $$1 if/config_msm_soc_rev_ (?! NONE) (\w+) =y/;$ $arch = $ $arch. LC ("$ $a $ $r") If/config_arch_ ((?: msm| qsd| MPQ) [a-za-z0-9]+] =y/} print $ $arch;

Get the above "dts_names" variable, with "$ (dts_name) *.dts" Way to "kernel/arch/arm/boot/dts/" under the match. See the definition below, where the "cat" command is to generate a kernelimage with dt.

Define APPEND-DTBMKDIR-P $ (kernel_out)/arch/arm/boot;$ (foreach Dts_name, $ (dts_names),    $ (foreach D, $ (dts_files) ,       $ (DTC)-P 1024-o dtb-o $ (call dtb_file,$ (d)) $ (d);       Cat $ (KERNEL_ZIMG) $ (call dtb_file,$ (d)) > $ (call zimg_file,$ (d));)) endef

For example, in the ES1 version of msm8974 MR2, the value of the "dts_names" variable is "msm8974 msmsamarium", which will be programmed into the file.

Msm8974pro-ab-cdp.dts     Msm8974pro-ac-mtp.dts  msm8974-v1-mtp.dts      Msm8974-v2.0-1-fluid.dts   Msm8974-v2.2-fluid.dts   Msmsamarium-sim.dtsmsm8974pro-ab-fluid.dts   Msm8974-v1-cdp.dts     Msm8974-v1-rumi.dts     Msm8974-v2.0-1-liquid.dts  Msm8974-v2.2-liquid.dtsmsm8974pro-ab-liquid.dts  Msm8974-v1-fluid.dts   Msm8974-v1-sim.dts      Msm8974-v2.0-1-mtp.dts     Msm8974-v2.2-mtp.dtsmsm8974pro-ab-mtp.dts     Msm8974-v1-liquid.dts  Msm8974-v2.0-1-cdp.dts  Msm8974-v2.2-cdp.dts       Msmsamarium-rumi.dts

The second way does not see how to put boot.img in the future. For the first way, "Dt.img" is compiled with the following rules defined in "Device/qcom/common/generate_extra_images.mk",

$ (Installed_dtimage_target): $ (Dtbtool) $ (installed_kernel_target) $ (build-dtimage-target)

The following statement is used in "build/core/makefile" to enable it to be programmed into boot.img.

Ifeq ($ (Strip $ (BOARD_KERNEL_SEPARATED_DT)), true)  Internal_bootimage_args + =--dt $ (installed_dtimage_target)  bootimage_extra_deps   : = $ (installed_dtimage_target) endif

the treatment in LK

8974 the actual use of the current should be mode 1. In the following BOOT_LINUX_FROM_MMC (), call Dev_tree_get_entry_info (), which will be based on the hardware (chipset and platform ID, The information of the actual running of the system is set by N side at the earlier stage of the system boot, and the information in DT is defined by the "Qcom,msm-id" attribute of the root node, then the DT is loaded into memory, and the address and other information is passed to kernel (allegedly through the CPU register).

Qcom,msm-id = <126 8 0x20002>,      <185 8 0x20002>,      <186 8 0x20002>;

Kmain ()  |bootstrap2 ()     |arch_init ()     |platform_init ()     |target_init () |apps_init (     )//call init ( ) of the APPs defined using App_start macro        |aboot_init ()           |boot_linux_from_mmc ()              |//for device tree approach 1< C8/>|dev_tree_get_entry_info ()                    |__dev_tree_get_entry_info ()                 |memmove ((void *) HDR->TAGS_ADDR, (char *) Dt_table_offset + Dt_entry.offset, dt_entry.size);              | For device tree approach 2                 |dev_tree_appended ()              |boot_linux ()                 |update_device_tree ()                 |entry (0 , Machtype, (unsigned*) Tags_phys);//pass control to Kernel

processing in the kernel

In the following SETUP_MACHINE_FDT (), the appropriate machine can be selected by matching the "Dt_compat" property of the machines description with the "compatible" attribute of the root node of the incoming dt. Description In the following board_dt_populate () processing, the device is created based on the Devicetree information.

Start_kernel ()  |setup_arch ()     |SETUP_MACHINE_FDT ()//select machine description according to DT Infocustomize_ Machine ()//called because it's an arch_initcall  |msm8974_init ()     |board_dt_populate ()        |of_platform_bus_ Create ()           |of_platform_device_create_pdata ()              |of_device_alloc ()                 |dev->dev.of_node = Of_node_get (NP  );//pointer to data of struct device_node, which is device node in DT           |of_platform_bus_create ()//call it recursively to Walk through the DT

A reference to the device node in DT is saved in the dev->dev.of_node above Of_device_alloc (). In the drive, the following ". Of_match_table" information is typically added for device and driver matching.

static struct of_device_id msm_otg_dt_match[] = {{. compatible = "QCOM,HSUSB-OTG",},{}};static struct Platform_driver MSM _otg_driver = {. remove = __devexit_p (msm_otg_remove),. Driver = {... of_match_table = Msm_otg_dt_match,},};

The following processing is called in KERNEL/DRIVERS/BASE/PLATFORM.C's Platform_match () for device and driver matching. Of_driver_match_device () is typically matched according to the "compatible" attribute (if name or type is set, the first match is based on Name/type).

if (Of_driver_match_device (Dev, DRV)) return 1;

Here are some APIs for device node operations (typically read).

Of_property_read_string () Of_find_property () Of_get_next_child () of_get_parent ()

"Turn" Android MSM8974 on the Devicetree profile----good