This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM5729: Sitara PinMux Tool Output File is Sparse - BBAI

Part Number: AM5729
Other Parts Discussed in Thread: AM5728

I am very stressfully trying to create/edit the .dts file for the BBAI, and I have gone through what pins that I need to configure, and the PinMux tool shows no errors.  When I finish, there is a file called "devidetree.txt" that I would assume holds the textual data to overide the .dts base configuration file (am5729-beagleboneai.dts) and allow me to create my own .dtb after compiling that down.

What I get is a text file with two sections, both blank.

Enclosed is the source PinMux tool "save" file for my project, as well as the .txt file that I would assume holds the correct textual drop-in data for my override .dts

What am I doing wrong?  I am not clear how to do this without having the devicetree.txt file reflect the work that I did in the tool!

2nd question -- I am using the Matrix image file from the SDK 6.03.00.106, and there are no tools there to create the dtb from the dts file.  All of the references on the TI WiKi and any other TI site is just not clear, not what I see on the build on the platform, or just not findable.  What I am using right now is the Cloud9 build, using their tools that are present in their latest image.  Here is what I did to get where I am, but of course I do not have the "data" to drop into my override .dts, as I mentioned above.

  1. git clone github.com/.../BeagleBoard-DeviceTrees -b v4.14.x-ti  
  2. create my own dts, using #include "am5729-beagleboneai.dts" at the top of my .dts file
  3. make src/arm/myfilename.dtb
  4. sudo cp src/arm/myfilename.dtb /boot/dtbs  
  5. sudo nano /boot/uEnv.txt (however this is not in /boot, but in /run/media/mmcblk1p1/boot instead????)

This is the last step for me being able to write code to talk to my hardware, and it has been a very long road to get here, to again, have the documentation be sparse, not there, or just plain wrong.

Th3225.AM5728_SR2.0_20200423.zip

/**
 * Note: This file was auto-generated by TI PinMux on 4/25/2020 at 2:10:14 PM.
 *
 * \file devicetree.txt
 *
 * \brief This file should only be used as a reference! This file contains
 *  register configuration information for the AM57xx Control Module. Two
 *  formats are provided in this file. The device tree (.dts) format WHICH 
 *  MAY CHANGE BETWEEN LINUX KERNEL VERSIONS and a generic format. For 
 *  summarization and description of the pad register bits refer to the
 *  "Control Module" chapter of the device Data Manual. This file should only
 *  be used as a reference. Some pins and/or peripherals, depending on your
 *  use case, may need additional configuration. Only MMC modes are exported
 *  here. All other pad configuration must be done by u-boot. 
 *
**/


/* * DEVICE TREE FORMAT PADCONF * */

&dra7_pmx_core {

};


/* * DEVICE TREE FORMAT IODELAY * */

&dra7_iodelay_core {
// for linux kernel 4.4 / processor sdk 3.x
};



/* * GENERIC FORMAT PADCONF * */



/* * GENERIC FORMAT IODELAY * */

anks!

  • Hello Jim,

    Regarding your first question:

    The devicetree exported from pinmux is just for reference. The SDK .dts files tend to change over time, so we cannot possibly support all permutations of the different distros, that's why we have it as reference. Also, only the MMC is exported in that file, because all other pin configuration must be done by u-boot. Here is an excerpt from the file description that explains this better:

    PMT said:

    * \file devicetree.txt
    *
    * \brief This file should only be used as a reference! This file contains
    * register configuration information for the AM57xx Control Module. Two
    * formats are provided in this file. The device tree (.dts) format WHICH
    * MAY CHANGE BETWEEN LINUX KERNEL VERSIONS and a generic format. For
    * summarization and description of the pad register bits refer to the
    * "Control Module" chapter of the device Data Manual. This file should only
    * be used as a reference. Some pins and/or peripherals, depending on your
    * use case, may need additional configuration. Only MMC modes are exported
    * here. All other pad configuration must be done by u-boot.

    If you want to use the tool data in your code, you should probably try one of the "generic file" dumps. From there, this data can be converted to whatever file format you may need. (.dts, iodelay calibration, uboot format, etc)

    Actually we do have a sample converter, that can read in generic file format from the tool, and convert it into mux_data.h that can be pasted over in the SDK folder and compiled. See this app note for more info:  

    I can't help you with the second question, it's not my area of expertise, so will ping SDK experts for comments,

    I hope it helps from PinMux tool perspective.

    thanks,

    Alex

  • Alex,

    I really appreciate the quick response, and I do appreciate that TI has to support all the distros out there.  uBoot should be somewhat consistent across builds, and this is where the devicetree stuff lives.  I can appreciate that we must have pin defines correct at boot time, and that I definitely do not want to kernel panic due to pion type conflicts.  This is a very high reliability machine that we are building, and no crashes are allowed!

    I am not clear as to how a developer is to go from a PinMux session, to a .dts, to a .dtb with any confidence.  The PinMux tool generates a file called "devicetree.txt" which is all sense, is blank.  There are some comments, yes, but no data. The document that you sent me does talk about the PinMux tool, and that for "Linux", but the output of these files are textual, and are in the format of:0x4844AA58 0 1900 CFG_VIN2A_D10_OUT D3

    but what the .dts wants is: DRA7XX_CORE_IOPAD(0x359C, MUX_MODE14) /* C2: P9.42b: vin2a_d13.off, for example.

    Where is the decoder doc for how to get from one, to the other?  Or to explain what the devicetree is all about?  I have a feeling that this is not a TI designed concept, I do just now see that there is a "devicetree.org" and they have docs, which are generic.

    The .dts file also has grouping of pin concepts, like: 

    &dra7_pmx_core {
    i2c4_pins: i2c4 {
    pinctrl-single,pins = <
    DRA7XX_CORE_IOPAD( P9_19a, PIN_INPUT_PULLUP | MUX_MODE7 ) // scl
    DRA7XX_CORE_IOPAD( P9_19b, PIN_INPUT_PULLUP | MUX_MODE14 ) // (shared pin)
    DRA7XX_CORE_IOPAD( P9_20a, PIN_INPUT_PULLUP | MUX_MODE7 ) // sda
    DRA7XX_CORE_IOPAD( P9_20b, PIN_INPUT_PULLUP | MUX_MODE14 ) // (shared pin)
    >;
    };

    Just trying to get past this stuck point, I must be really old and slow in my old age, this just should not be this hard!  TI has to give out "how to" docs when using the PinMux.  And I cannot be the first to have these questions!

    Appreciate the time, really.  Hope that you and the team are safe!

  • Alex,

    I just saw the perl script that tool the two .txt files and output a single text file, that looks hopeful.

    {GPMC_A0, (M7 | PIN_INPUT)}, /* R6 gpmc_a0.i2c4_scl */
    {GPMC_A1, (M7 | PIN_INPUT)}, /* T9 gpmc_a1.i2c4_sda */

    however is not the same as

    DRA7XX_CORE_IOPAD( P9_19a, PIN_INPUT_PULLUP | MUX_MODE7 ) // scl
    DRA7XX_CORE_IOPAD( P9_20a, PIN_INPUT_PULLUP | MUX_MODE7 ) // sda

    Guess I just need to keep searching for other docs...

  • Hello Jim,

    No problem, we will try to get you going as fast as we can, and I agree it's not that straight forward to understand from the start.

    So on your last reply, again, I don't think SDK is using devicetree (at least not currently). AFAIK the mixing is done in the mux_data header file not in the .dts file. That said, see this post: https://e2e.ti.com/support/processors/f/791/t/816721 , it should help you update your configuration all the way from tool export data to compiling the SDK.

    Let us know if this helps,

    Have a good one,

    Alex

  • Alex,

    I was able to use the perl scripts, but those still do not "get me there" to the devicetree .dts file format.  Here is a rant from me, that may help to understand where I am today!  I am no closer to having a .dts that I can compile into the .dtb for uBooting...

    I am using the latest TI SDK, ti-processor-sdk-linux-am57xx-evm-06.03.00.106.  I am simply using the image there that boots Matrix, so this is not a strange flavor of distro or build.  I am also using the BeagleBone AI (BBAI) board for this work, and I have loaded the TI image there.
    I have created my PinMux documents, and I of course thought that this was as simple as dropping files into a directory, and wallah, all done.  I had an awakening.
    Here is THE QUESTION
    What is the best method to get my pins into uBoot, as well as what do I need to load into my source code to manage the defines created by the PinMux too?
    I finally dove deep into the #include file set, and finally saw dra.h, and that helped me to understand where the root #define set came from.  One of the questions has been, how is remoteproc populated, and I can see in the include files that is where that happens.  I noted that on the BBAI board, remoteproc moves depending on if I use the Cloud9 build, or the TI image.  That all has to be defined in this same devicetree structure.
    So, what is the easiest method to go from the PinMux, or .csv output, to the final .dts file that would "override" the baseline BBAI board?  A line like this from the .csv file: vout1_d4,vout1,PD,PD,vddshv2,,,E9,PRUSS1_eCAP,pr1_ecap0_ecap_capin_apwm_o,,FALSE,FALSE,FALSE,PRU1_PWM
    needs to be coverted to this, I believe: DRA7XX_CORE_IOPAD(0x35EC, MUX_MODE14) /* E9: P8.41: vout1_d4.off */
    But I don't see the correlation: where is the PRU mux defined to allow me to get the PWM out to E9?  
    The TRM is 8063 pages long, I see there if we stay on the same topic, my PRU PWM pin at ball E9, a section in the TRM 30.1.4.5.2.2 PRUSS_CFG Register Description, but I don't see MUX_MODE14 or any other mode set there.
    This just has to be easier, I don't have the right docs!  I am sure that I will also have to configure registers to get them to work too, right?  Or is that all in the devicetree setup, and I will not have to do any more register writes to configure the cores, modules or functions?
  • Couple more notes. maybe it is me thinking that this is more than it is...I suspect that if I define the pin in my .dts top level, that OVERRIDES all the other #includes in the tree, or else there would be conflicts...I did run the perl script, and the output is still not aligned with the .dts format, however it looks closer.

    If we look at just these two lines which define i2c port 4, ball P9...

    {GPMC_A0, (M7 | PIN_INPUT)}, /* R6 gpmc_a0.i2c4_scl */
    DRA7XX_CORE_IOPAD(0x3440, PIN_INPUT_PULLUP | MUX_MODE7) /* R6: P9.19a: gpmc_a0.i2c4_scl */
    those match, so that is not much help to decode this.

    Here is that PRU PWM pin again...
    PinMux Output
    vout1_d4,vout1,PD,PD,vddshv2,,,E9,PRUSS1_eCAP,pr1_ecap0_ecap_capin_apwm_o,,FALSE,FALSE,FALSE,PRU1_PWM
    iopad..txt output
    {VOUT1_D4, (M10 | PIN_OUTPUT)}, /* E9 vout1_d4.pr1_ecap0_ecap_capin_apwm_o */
    and make it
    DRA7XX_CORE_IOPAD(0x35EC, MUX_MODE10) /* E9: P8.41: vout1_d4.on*/

    Here are my listings in case that matters:

    iopad.txt

    {GPMC_A0, (M7 | PIN_INPUT)}, /* R6 gpmc_a0.i2c4_scl */
    {GPMC_A1, (M7 | PIN_INPUT)}, /* T9 gpmc_a1.i2c4_sda */
    {VIN1A_D7, (M14 | PIN_INPUT)}, /* AH4 vin1a_d7.gpio3_11 */
    {VIN2A_D2, (M10 | PIN_OUTPUT)}, /* D1 vin2a_d2.eCAP1_in_PWM1_out */
    {VIN2A_D9, (M14 | PIN_INPUT)}, /* E6 vin2a_d9.gpio4_10 */
    {VIN2A_D10, (M13 | PIN_OUTPUT | MANUAL_MODE)}, /* D3 vin2a_d10.pr1_pru1_gpo7 */
    {VIN2A_D12, (M13 | PIN_OUTPUT | MANUAL_MODE)}, /* D5 vin2a_d12.pr1_pru1_gpo9 */
    {VIN2A_D13, (M13 | PIN_OUTPUT | MANUAL_MODE)}, /* C2 vin2a_d13.pr1_pru1_gpo10 */
    {VIN2A_D14, (M12 | PIN_INPUT | MANUAL_MODE)}, /* C3 vin2a_d14.pr1_pru1_gpi11 */
    {VIN2A_D17, (M13 | PIN_OUTPUT | MANUAL_MODE)}, /* D6 vin2a_d17.pr1_pru1_gpo14 */
    {VIN2A_D18, (M13 | PIN_OUTPUT | MANUAL_MODE)}, /* C5 vin2a_d18.pr1_pru1_gpo15 */
    {VIN2A_D20, (M13 | PIN_OUTPUT | MANUAL_MODE)}, /* B3 vin2a_d20.pr1_pru1_gpo17 */
    {VIN2A_D21, (M13 | PIN_OUTPUT | MANUAL_MODE)}, /* B4 vin2a_d21.pr1_pru1_gpo18 */
    {VOUT1_D0, (M13 | PIN_OUTPUT | MANUAL_MODE)}, /* F11 vout1_d0.pr2_pru1_gpo18 */
    {VOUT1_D1, (M13 | PIN_OUTPUT | MANUAL_MODE)}, /* G10 vout1_d1.pr2_pru1_gpo19 */
    {VOUT1_D2, (M10 | PIN_INPUT)}, /* F10 vout1_d2.pr1_uart0_rxd */
    {VOUT1_D3, (M10 | PIN_OUTPUT)}, /* G11 vout1_d3.pr1_uart0_txd */
    {VOUT1_D4, (M10 | PIN_OUTPUT)}, /* E9 vout1_d4.pr1_ecap0_ecap_capin_apwm_o */
    {VOUT1_D13, (M10 | PIN_INPUT)}, /* C6 vout1_d13.pr2_uart0_rxd */
    {VOUT1_D14, (M10 | PIN_OUTPUT)}, /* C8 vout1_d14.pr2_uart0_txd */
    {VOUT1_D15, (M10 | PIN_OUTPUT)}, /* C7 vout1_d15.pr2_ecap0_ecap_capin_apwm_o */
    {VOUT1_D18, (M14 | PIN_INPUT)}, /* A7 vout1_d18.gpio8_18 */
    {XREF_CLK0, (M13 | PIN_OUTPUT | MANUAL_MODE)}, /* D18 xref_clk0.pr2_pru1_gpo5 */
    {XREF_CLK1, (M13 | PIN_OUTPUT | MANUAL_MODE)}, /* E17 xref_clk1.pr2_pru1_gpo6 */
    {MCASP1_AXR0, (M13 | PIN_OUTPUT | SLEWCONTROL | MANUAL_MODE)}, /* G12 mcasp1_axr0.pr2_pru1_gpo8 */
    {MCASP1_AXR1, (M13 | PIN_OUTPUT | SLEWCONTROL | MANUAL_MODE)}, /* F12 mcasp1_axr1.pr2_pru1_gpo9 */
    {MCASP1_AXR8, (M13 | PIN_OUTPUT | SLEWCONTROL | MANUAL_MODE)}, /* B12 mcasp1_axr8.pr2_pru1_gpo10 */
    {MCASP1_AXR9, (M13 | PIN_OUTPUT | SLEWCONTROL | MANUAL_MODE)}, /* A11 mcasp1_axr9.pr2_pru1_gpo11 */
    {MCASP1_AXR10, (M13 | PIN_OUTPUT | SLEWCONTROL | MANUAL_MODE)}, /* B13 mcasp1_axr10.pr2_pru1_gpo12 */
    {MCASP1_AXR11, (M13 | PIN_OUTPUT | SLEWCONTROL | MANUAL_MODE)}, /* A12 mcasp1_axr11.pr2_pru1_gpo13 */
    {MCASP1_AXR13, (M13 | PIN_OUTPUT | SLEWCONTROL | MANUAL_MODE)}, /* A13 mcasp1_axr13.pr2_pru1_gpo15 */
    {MCASP1_AXR14, (M10 | PIN_INPUT | SLEWCONTROL)}, /* G14 mcasp1_axr14.timer11 */
    {MCASP1_AXR15, (M14 | PIN_INPUT | SLEWCONTROL)}, /* F14 mcasp1_axr15.gpio6_6 */
    {MMC3_CLK, (M14 | PIN_INPUT)}, /* AD4 mmc3_clk.gpio6_29 */
    {MMC3_CMD, (M10 | PIN_INPUT)}, /* AC4 mmc3_cmd.eCAP2_in_PWM2_out */
    {MMC3_DAT0, (M14 | PIN_INPUT)}, /* AC7 mmc3_dat0.gpio6_31 */
    {MMC3_DAT2, (M14 | PIN_INPUT)}, /* AC9 mmc3_dat2.gpio7_1 */
    {MMC3_DAT3, (M14 | PIN_INPUT)}, /* AC3 mmc3_dat3.gpio7_2 */
    {MMC3_DAT4, (M14 | PIN_INPUT)}, /* AC8 mmc3_dat4.gpio1_22 */
    {MMC3_DAT5, (M14 | PIN_INPUT)}, /* AD6 mmc3_dat5.gpio1_23 */
    {MMC3_DAT6, (M14 | PIN_INPUT)}, /* AB8 mmc3_dat6.gpio1_24 */
    {MMC3_DAT7, (M10 | PIN_OUTPUT)}, /* AB5 mmc3_dat7.eCAP3_in_PWM3_out */
    {SPI2_SCLK, (M1 | PIN_INPUT)}, /* A26 spi2_sclk.uart3_rxd */
    {SPI2_D1, (M1 | PIN_OUTPUT | SLEWCONTROL)}, /* B22 spi2_d1.uart3_txd */

    iopdelay.txt

    {0x03C8, 0, 800}, /* CFG_MCASP1_AXR0_OUT */
    {0x03D4, 0, 2300}, /* CFG_MCASP1_AXR10_OUT */
    {0x03E0, 0, 600}, /* CFG_MCASP1_AXR11_OUT */
    {0x03F8, 0, 1500}, /* CFG_MCASP1_AXR13_OUT */
    {0x041C, 0, 1400}, /* CFG_MCASP1_AXR1_OUT */
    {0x0470, 0, 2000}, /* CFG_MCASP1_AXR8_OUT */
    {0x047C, 0, 800}, /* CFG_MCASP1_AXR9_OUT */
    {0x0A58, 0, 1900}, /* CFG_VIN2A_D10_OUT */
    {0x0A70, 0, 3400}, /* CFG_VIN2A_D12_OUT */
    {0x0A7C, 0, 3200}, /* CFG_VIN2A_D13_OUT */
    {0x0A80, 0, 0}, /* CFG_VIN2A_D14_IN */
    {0x0AAC, 0, 3000}, /* CFG_VIN2A_D17_OUT */
    {0x0AB8, 0, 2200}, /* CFG_VIN2A_D18_OUT */
    {0x0ADC, 0, 1800}, /* CFG_VIN2A_D20_OUT */
    {0x0AE8, 0, 1900}, /* CFG_VIN2A_D21_OUT */
    {0x0BA8, 0, 0}, /* CFG_VOUT1_D0_OUT */
    {0x0C2C, 0, 0}, /* CFG_VOUT1_D1_OUT */
    {0x0CF8, 0, 1600}, /* CFG_XREF_CLK0_OUT */
    {0x0D04, 0, 1500}, /* CFG_XREF_CLK1_OUT */

  • Hello Jim,

    Let me sync with SDK team on this and get back to you soon.

    Thanks,

    Alex

  • Thank you, one more question...

    http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/How_to_Guides/Target/How_to_Change_dtb_File.html

    says that the uEnv.txt file to edit is in the “/run/media/mmcblk0p1” directory on filesystem)

    but the .dtb file set and the uEnv.txt file that potentially "points" to the .dtb file is in: /run/media/mmcblk1p1/boot

    on the TI SDK image that is in the latest SDK ti-processor-sdk-linux-am57xx-evm-06.03.00.106-Linux


    I really don't want to brick the install, so just confirming that the wiki information page is not correct...it needs to be updated?

  • Apologize to keep adding to this, but the perl script can output two files, iopad and iodelay.

    I don't see where iodelay gets used?

  • Hello Jim,

    the IODelay values are a must for delay calibration on the AM5xxx devices. Now where these are used in the SDK I'm not sure, that's why want to touch base with SDK team, waiting on feedback from them, just sent a reminder today.

    thanks,
    Alex

  • Hello Jim,

    Here is the feedback I got from SDK team:

    Due to iodelay all the pinmux related configuration is done at U-boot. So, all the pin mux configuration(with few exceptions) happens inside U-Boot. Here is an app note[0] with all the details and usage of PMT.

    Let me know if something is not clear in the app note.

     

    [0] https://www.ti.com/lit/an/sprac44a/sprac44a.pdf?&ts=1588926854517

    So, like I said a few posts back, forget about the other dts files and formats, and follow the doc which should get you there. Let us know if that helps

    thanks,

    Alex

  • Alex,

    Just to let you know, I ended up going back to the BeagleBone AI Cloud9 distro, since it works.  I used the devicetree method, and uEnv.txt is right there where it should be, I can point it to the right .dtb file, reboot, and it just works.  Of coruse the distro is not the TI build, but good enough to keep me going until I can move back to the TI version.

    Right now your repo is busted for pulling packages or doing an update, so the EVM flash build is not fun to use, I am very scared to wget code from places that you all have not qualified, since well, this is not an Unbuntu system that can handle generic packages.

    I will hopefully be able to get back to your distro and make that work, when I have the software tools needed, that are not in the default package.

  • Jim,

    Alright, thanks for the feedback, and glad to hear you got moving a bit with this. Let us know if we can help further. I will close this thread now and you can open a new one if you need additional assistance with TI SDK.

    thanks,

    Alex

  • In the App note:   Page 21 Clearly mentions the following:

    "The two text files generated by the script can now be used to modify the contents of the mux_data.h
    header file that exists in board/ti/am57xx within the u-boot source directory. Note the default header file
    included with the Processor SDK splits the board configuration data into multiple data structures to
    support multiple AM57xx EVMs. The data structures are used by the board.c file within the same directory.
    The particular set of pad configuration settings used will depend on the results of board detection using
    the on-board EEPROM. Recompile u-boot after updating these files"

    Have you tried updating your output in mux_data.h ?

    Thanks and regards,

    Lokesh

  • Lokesh,

    Right now, I have to keep working where I know that I can work.  The latest 6.03.00.106 SDK image files have so many things missing, opkg repo broken. dependencies for my scripts/programs that work great on the BeagleBone distro, uBoot update instructions out of date, etc. that I cannot take the time to go and make sure that works.  For final production, yes, that is where I need to go, but for now, until you all get that all fixed up, I am a little crippled with that image.  For now, using the BBAI 10.3 TIDL distro that I know works, and is predictable to my flow.

    Better for me to wait for you all to fix the issues, docs, etc. so that I feel comfortable with repeatability and reliability...and a method for future disto build consistency.  I was great with the older distro, the only metric that I have is when apt worked, oplg boundary change, where a lot seems to have changed.

  • Hi Jim,

    I just reviewed a few posts that you made, and we will take care of addressing those.

    But specifically with regard to this thread, are there any topic questions from your side. I believe that the original questions have been answered in the earlier posts, but if not please provide a summary and we will take it forward.

    Regards

    Karthik

  • For now, I am using the Cloud9 build, and that is working for me.  I cannot take that to production, so I can remap sysfs stuff when that times comes, I have noted that all of the remoteproc stuff moves from their build to the TI build, still learning about the devicetree method of system definition, have a feeling that is where it has to be defined.  If we move to the iomux method of defining pins later, I am ready for that as well.

    But yes, for now, this thread can be closed, thank you.