AM5718: Pinmux tool doesn't generate .DTS file

Jeff Andich

Part Number: AM5718
Other Parts Discussed in Thread: TMDSEVM572X

Hi,

When you generate a pinmux design using the cloud-based pinmux tool for the AM5718, and select Device: AM5718_SR2.0_BETA, currently the tool doesn't produce devicetree file output for the generated files. This also seems to be the case for any device which is in Beta status on the pinmux tool, correct?

Is there any other way to auto-generate device tree output when you generate a pinmux configuration using this utility or is there another utility or means to auto generate a device tree file from the pinmux configuration?

Thanks!

Jeff Andich

over 8 years ago

0 Biser Gatchev-XID over 8 years ago

TI__Guru**** 393215 points

Hi,

The Pinmux team have been notified. They will respond here.

0 Alex Bashkov over 8 years ago

TI__Genius 13550 points

Hi Jeff,

The current cloud version has the device tree file output for AM572x devices only. The device tree output will be available for the AM571x devices in the upcoming tool version, which should be available soon. That said, the device tree file named that way is a bit confusing since it will only produce the MMC/DCAN "runtime pad configuration". We may decide to change file output nomenclature to avoid confusion, but bottom line is that output format will produce only MMC/DCAN runtime pad configuration.

What you probably need is to generate a complete "device tree" uboot format file to use in the source code. In order to do so, please study the PinMux tool app note available here: which explains how to configure the tool, generate the files as needed and post-process them via the attached script am57xx_uboot_pin_config-master.zip to obtain the final desired pad configuration code.

Hope it helps,

Thanks,

Alex

0 Jeff Andich over 8 years ago in reply to Alex Bashkov

Intellectual 890 points

Thanks Alex!

Will take a look at it, and let you know if I have questions, intermediate results, or potentially useful information to someone else on the forum..

0 Jeff Andich over 8 years ago in reply to Jeff Andich

Intellectual 890 points

So if I understand the process of customizing the connection of IO pads to peripherals correctly (from looking at the SPRAC44 document):

* Most of the I/O pads, except for MMC, can only get associated with peripherals and other signals at boot time when the SPL/MLO is running from internal SRAM on the 57xx chip.

*The perl script, am57xx_generate_pin_config_data.pl, generates IO pad configuration and IO delay table which are incorporated into the mux_data.h header file which is used to build the MLO.

*When the custom built MLO runs, it first sets up all of the static pad configuration settings on the chip, associating the BGA pins to peripherals.

*The MLO then kicks off the "runtime code" (Rest of U-boot, kernel boot, FS mount, etc), by loading U-boot into external SRAM, and jumping to U-boot.

*!!Then when the kernel boots and processes the DTB, the system can no longer statically configure the I/O pad or pinmux (see questions below).

*The only pinmux/IO pad settings which can be configured by the kernel are the MMC settings.

Questions:

1) Is there a document or wiki for the TI processor SDK (maybe as part of the Getting Started Guide) for the am57xx chip which describes the entire process of adapting/tailoring the TI LInux SDK pinmux and IO pad configuration settings for a custom hardware board which "designs in" the 57xx part? Or is it really as simple as generating the header file from the pinmux tool output then the perl script, then building U-boot?

2) Is the mux_data.h header file only for the MLO portion of U-boot?

3) Is the above statement that static pinmux IO pad settings (associations between peripherals and pads/BGA pins) only happen in the MLO at initial boot time correct or are there other cases when the kernel loads the MLO and static IO pad configuration occurs?

Thanks!!!

Jeff

0 Alex Bashkov over 8 years ago in reply to Jeff Andich

TI__Genius 13550 points

Hi Jeff,

I will bring in the software team here as your questions are somewhat out of pinmux tool scope and they should have more precise answers.

thanks,
Alex

0 Yordan Kovachev over 8 years ago in reply to Jeff Andich

TI__Guru**** 161600 points

Hi Jeff,

Your understanding about the process is generally correct.

Now to answer your questions:

1). No, we do not have such Wiki or user guide yet, not sure if there is a plan to create one.. this is a generic linux/u-boot porting stuff.

Or is it really as simple as generating the header file from the pinmux tool output then the perl script, then building U-boot?

Yes, pinmuxing is as simple as creating the mux_data.h file with entries that correspond to your use case. Then the board.c file configures the device pads using the definitions in mux_data.h

2). Yes.

3) Yes, this is correct. However, you can override the device pinmuxing or do additional pinmux settings from linux kernel by adding entries in the am57xx dts file. Specified pinmux settings should take effect as soon as kernel takes over.

Hope this helps.

Best Regards,
Yordan

0 Jeff Andich over 8 years ago in reply to Yordan Kovachev

Intellectual 890 points

Thank you Yordan for taking the time to answer my newbie questions!

Regarding #3, are the dts pinmux overrides limited ONLY to MMC pinmux, since these are done at runtime or is there also a way to re-configure the other pinmux?

Also, sprac44 indicates that pinmux files for the TI 572X EVM are available at www.ti.com/.../tmdsevm572x, but I haven't yet found them.

Ideally there would be a file we can load into the pinmux tool to reproduce the pinmux/IO pad config and timing of the 572xEVM. Do you know if the pinmux tool file and/or other output files (e.g. genericFileFormatPadConf.txt, IOdelay.txt, ....) exist for either the 572xEVM or the 571xIDK?

Thanks again!

Jeff

0 Rogerio Almeida over 8 years ago in reply to Jeff Andich

TI__Mastermind 26205 points

Jeff,
regarding "Also, sprac44 indicates that pinmux files for the TI 572X EVM are available at www.ti.com/.../tmdsevm572x, but I haven't yet found them. " - thanks for catching this....I will check Monday what happened...

0 Yordan Kovachev over 8 years ago in reply to Jeff Andich

TI__Guru**** 161600 points

Hi Jeff,

You could reconfigure all pinmux settings if you add the corresponding entries in the dts file.

Best Regards,
Yordan

0 Jeff Andich over 8 years ago in reply to Yordan Kovachev

Intellectual 890 points

Thanks Yordan!

I think I failed to make it clear that I'm talking about configuring/re-configuring the MUXMODE register for each applicable pad, since we're making a custom board with the 5718. The TRM and SPRAC44 indicate that in Linux, this must be done at "boot time" in isolation mode from code running from internal SRAM, section 18.4.6.1.7 of the TRM (spruhz6h.pdf).

I understand that for MOST of the peripherals, except for the MMC, the MUXMODE registers can only be written in isolation mode by the MLO loaded into internal SRAM.

If I look at the device tree file for the 572x EVM, am57xx-evm-reva3.dts, I only see MUXMODE configuration of mmc PAD registers:

**am57xx-evm-reva3.dts**

&dra7_pmx_core {

/*
* TODO: We should be able to move PinMux values defined here to
* am57xx-beagle-x15-revb1.dts once that board is available and
* its MMC/SD interface is verified. For now these stay here until
* that exercise is complete.
*/

mmc1_pins_default: mmc1_pins_default {
pinctrl-single,pins = <
DRA7XX_CORE_IOPAD(0x3754, (PIN_OUTPUT_PULLUP | MUX_MODE0)) /* mmc1_clk.clk */
DRA7XX_CORE_IOPAD(0x3758, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc1_cmd.cmd */
DRA7XX_CORE_IOPAD(0x375c, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc1_dat0.dat0 */
DRA7XX_CORE_IOPAD(0x3760, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc1_dat1.dat1 */
DRA7XX_CORE_IOPAD(0x3764, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc1_dat2.dat2 */
DRA7XX_CORE_IOPAD(0x3768, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc1_dat3.dat3 */
.
.
.
}

Do you mean that there are certain exceptions to when the Sitara chip really needs to be in isolation mode (e.g. its really ok to re-configure the MUXMODE register in the kernel (running from external SDRAM) for functions like UART and GPIO pads so long as the UART isn't running)?

Or are you talking about something else?

Thanks for your patience!!

Jeff

0 Yordan Kovachev over 8 years ago in reply to Jeff Andich

TI__Guru**** 161600 points

Hi Jeff,

I understand that for MOST of the peripherals, except for the MMC, the MUXMODE registers can only be written in isolation mode by the MLO loaded into internal SRAM.

It is actually possible to reconfigure the registers from kernel (which is executed from DDR). You can add the corresponding pinmux settings in the kernel dts file & linux kernel will reconfigure the pinmux settings upon bootup.

As for the IODELAY settings for MMC, see the comments in drivers/pinctrl/pinctrl-ti-iodelay.c:
/**
* ti_iodelay_pinconf_set() - Configure the pin configuration
* @iod: IODelay device
* @val: Configuration value
*
* Update the configuration register as per TRM and lockup once done.
* *IMPORTANT NOTE* SoC TRM does recommend doing iodelay programmation only
* while in Isolation. But, then, isolation also implies that every pin
* on the SoC(including DDR) will be isolated out. The only benefit being
* a glitchless configuration, However, the intent of this driver is purely
* to support a "glitchy" configuration where applicable.
*
* Return: 0 in case of success, else appropriate error value
*/

In latest SDK (kernel 4.4.41) the registers are unlocked and can even be accessed & modified from userspace with devmem2.

Best Regards,
Yordan

0 Jeff Andich over 8 years ago in reply to Yordan Kovachev

Intellectual 890 points

Thank you Yordan!!

Very interesting!

Two follow up questions:

1) Is it still possible that we will need a custom IO PAD configuration in u-boot, just to get the kernel up and running, where the rest of the IO Pad configuration can be done by the kernel using our DTS with the IO PAD configurations?

2) We're still using kernel version 4.4.30. Does the pinctrl-ti-iodelay, driver in that kernel version, also handle the glitches in DTS IO pad configuration?

Thanks!

Jeff

0 Yordan Kovachev over 8 years ago in reply to Jeff Andich

TI__Guru**** 161600 points

Hi Jeff,

1) Is it still possible that we will need a custom IO PAD configuration in u-boot, just to get the kernel up and running, where the rest of the IO Pad configuration can be done by the kernel using our DTS with the IO PAD configurations?

Yes, you need custom u-boot configurations to get your bootloader up and running (i.e. if you boot from nand, you'll need the gpmc pinmux set, similarly for emmc boot you'll need mmc pinmux and so on..), and later for the u-boot to get the kernel. You can do additional IO pad configurations in linux kernel.

We're still using kernel version 4.4.30. Does the pinctrl-ti-iodelay, driver in that kernel version, also handle the glitches in DTS IO pad configuration?

Glitchless configuration is supported only in SPL (MLO), which runs from SRAM, see the comment from my previous post (this is taken from the kernel driver):

"But, then, isolation also implies that every pin

* on the SoC(including DDR) will be isolated out. The only benefit being

* a glitchless configuration, However, the intent of this driver is purely

* to support a "glitchy" configuration where applicable."

Best Regards,
Yordan

0 Jeff Andich over 8 years ago in reply to Yordan Kovachev

Intellectual 890 points

Thanks Yordan!

I'm working on changing the IO PAD configuration by editing the array in mux_data.h and confirming that the changes to the array result in changes to the PAD configuration which can be seen on the sysfs interface when the kernel and FS are up and running. Will let you know when I have questions.

The one thing that's stumped me is when I put printf's or puts strings in board.c: recalibrate_iodelay, before the call to ret = __recalibrate_iodelay_start(), the strings aren't printed out on console when the MLO is running.

I put the printf's in this function to confirm that recalibrate_iodelay is being called on every power-up and to determine which board type the 572X thinks it is so that I know which arrays from mux_data.h are used to configure the IO PAD configuration and PAD delays.

0 Yordan Kovachev over 8 years ago in reply to Jeff Andich

TI__Guru**** 161600 points

Hi,

I put the printf's in this function to confirm that recalibrate_iodelay is being called on every power-up and to determine which board type the 572X thinks it is so that I know which arrays from mux_data.h are used to configure the IO PAD configuration and PAD delays.

It is possible that the debug uart was not enabled yet, so you can't print debug output on the console.
Try for example using the printf in any other driver, i.e. omap_hsmmc.c or omap_gpio.c etc and you'll see that this works.

Best Regards,
Yordan

Processors

Processors forum

AM5718: Pinmux tool doesn't generate .DTS file