i.mx7 Device tree and PINS tool source code export

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.mx7 Device tree and PINS tool source code export

1,670 Views
demoniacmilk
Contributor IV

Hello community!

It took me quite some time to figure out how to create/adjust/change a custom device tree file for linux, but I finally I have managed to compile the device tree and can go ahead to create a device tree for custom hardware.

The DTSI file discribes every function that the SoC has (CPUs, perihperals, controllers, ..).
The DTS file describes the system. It imports the dtsi file and enables some of the peripherals described in the dtsi file. It also handles pin muxing and description of external devices.
DTS is compiled to a DTB (binary) using the device tree compiler DTC. To actually have this work, the DTS file has to be processed by a C preprocessor first (like CPP) and the result passed to DTC.


But there are some things that are quite strange.

  1. ) the DTS file contains a lot of lines similar to
         linux,something = "value";
    every time the preprocessor has processed the DTS file, there are 4 instances or "linux," that have been replaced by "1,". Any idea why this could happen?
  2. The dtsi output file generated by the PINS tool seems to only contain info on the PIN mux. From what I understood, this should be part of the DTS file, not the DTSI file? As the pinout is a description of the system, not the SoC.
    The exported file describes only the iomux module, followed by the pin setup. Is this just meant to provide a starting point to create the actual DTS file? It could contain info on e.g. the cpu or other modules like i2c/uart/spi etc?
  3. When looking at the pin_mux.c file exported using PINS, I can see that the pins are assigned to the desired function: HW_IOMUXC_SW_MUX_CTL_PAD_EPDC_SDCE3_WR(
       IOMUXC_BASE,      
         BF_IOMUXC_SW_MUX_CTL_PAD_EPDC_SDCE3_MUX_MODE(
        BV_IOMUXC_SW_MUX_CTL_PAD_EPDC_SDCE3_MUX_MODE_ALT2_ENET2_RGMII_TD1)
    );
    So, in this case, the EPDC_SDCE3 pin is used for RGMII_TD1, what is the pins alternate function #2.

    I do not understand how the numbering in the DTS(I) file works.
    The default sabre DTS file file contains
    MX7D_PAD_EPDC_SDCE3__ENET2_RGMII_TD1        0x1

    MX7D_PAD_... is expanded to multiple numbers, like
    0x1048 0x08BD 0x0000 0x0005 0x0000
    and the first two values seem to be related to registers, the second last is the alternate pin function number.

    The exported DTSI file contains e.g.
    MX7D_PAD_EPDC_SDCE3__ENET2_RGMII_TD1       0x00000014
    what is different to the ogirinal file (0x14 instead 0x1). In fact, EVERY pin in the exported file has the value 0x14. What does this value mean?

 

Thanks for helping me understand,
Lars

0 Kudos
Reply
1 Reply

917 Views
Carlos_Musich
NXP Employee
NXP Employee

Hi Lars,

DTSI files are include files for DTS files. At the end of the day you can write everything in a DTS file but it will be more ordered if you use DTSI files. Actually when you decompile a .dtb into a .dts it will generate a single .dts that includes everything that was included (.dts and .dtsi files) to generate the .dtb file.

The numbers assigned to the macro are the Pad Mux Reg and Pad Control Reg offsets and the pin mux Alt selected for that pin. And the number besides the macro is the value of the Pad Control Reg. The following thread explains a good example:

32Khz clock on CCM_CLKO2 (SD1_WP) 

To develop your custom device tree this post will be helful

Basic Device Tree for the Udoo Board 


Regards,
Carlos

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
Reply