• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 1500 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Linux/TMDSEVM572X: Pad configuration questions

Jeff Andich
Intellectual 890 points
Part Number: TMDSEVM572X
Other Parts Discussed in Thread: AM5728

Tool/software: Linux

Hi,

In u-boot's pad configuration for the 572x, the pad configuration registers appear to be written in two separate steps/stages, first the primary pad configurations, followed by the "delta array" pad configurations.  These two arrays appear in mux_data.h, and the pad IO configurations appears to be done in two separate stages in recalibrate_iodelay() in board.c:

1) First initialization step in recalibrate_iodelay() writes the pad configuration registers using the primary pad configuration array (e.g. core_padconf_array_essential_X15)

2) Second initialization step in recalibrate_iodelay() writes the pad configuration registers from the "delta" array  (e.g. core_padconf_array_delta_X15) which appears to be mainly VIN/VOUT, mux mode 0..

*The PERL script in the pinmux app note, sprac44 (I'm using an older version), generates one big table in padconf.h containing ALL pad configurations, including VOUT, VIN, and then it looks  like  you need to split the VOUT/VIN entries from the PERL script output into the "delta array" and put everything else in the main, array (pad configuration essential).

Questions:

1)  Why are the pad configuration register writes split up into two stages like this, primary and then delta?  What were to happen if you wrote everything in one big loop as opposed to breaking this up?  Is this due to needing to bound the execution time of each configuration step or is there something about needing to bring up video after everything else?

2) Does this order dependency of first configuring all non-video pads, followed by analog video pads (e.g. the delta array) only pertain to pads configured for analog video?

3) if we re-configure a PAD who's M0 mode is analog video to a different mux mode (see example below), do we still need to place that particular pad configuration into the delta array element or can that pad configuration be placed in the primary array?

{VOUT1_D12, (M0 | PIN_OUTPUT | SLEWCONTROL | MANUAL_MODE)}, /* vout1_d12.vout1_d12 */

{VOUT1_D12, (M10 | PIN_OUTPUT)}, /* vout1_d12.pr2_uart0_rts_n */

I don't THINK this addressed in sprac 44.  If I missed the explanation in the TRM, please forgive me!

Thanks!!!

Jeff

  • 0
    TI__Guru**** 170625 points
    Hi Jeff,

    I will have a deeper look into your questions, but as a starting point, please note that we have requirement to pinmux almost everything in first stage bootloader.

    All pinmux or IODelay configurations (with the exception of MMC) need to occur in isolation mode. However, as described in the "Isolation Requirements" section of the AM572x TRM: "when the IOs are isolated, code must execute only from internal RAM." This is because isolation mode impacts all IOs and the DDR will not be accessible. Therefore, isolation mode and pinmux configuration must be done at boot time. Run-time pinmux changes in the kernel are not supported.

    See also AM572x Silicon errata:
    i869 IO Glitches Can Occur When Changing IO Settings

    See also below links:

    e2e.ti.com/.../1995178
    e2e.ti.com/.../540246
    e2e.ti.com/.../571589

    Regards,
    Pavel
  • 0 in reply to Pavel Botev
    Intellectual 890 points
    Yes indeed sir.

    Per the snippets of recalibrate_iodelay below, the pad configuration is broken into 2 steps:

    For those of us doing custom board ports for the 5728, we just need to know when to split up the pad configurations. I'm sure the info is out there somewhere, but I haven't yet found a good rule of thumb or an explanation why...

    Thanks again!!

    Jeff


    Excerpts from board.c
    **********************

    In u-boot/board/ti
    void recalibrate_iodelay(void)
    {
    .
    .
    pconf = core_padconf_array_essential_x15;
    .
    .
    /* Setup I/O isolation */
    ret = __recalibrate_iodelay_start();

    /* Do the muxing here */
    do_set_mux32((*ctrl)->control_padconf_core_base, pconf, pconf_sz);
    .
    .
    /* Now do the weird minor deltas that should be safe */

    pconf = core_padconf_array_delta_x15_sr2_0;
    .
    .
    do_set_mux32((*ctrl)->control_padconf_core_base, pconf, pconf_sz);
    .
    .
    /* Closeup.. remove isolation */
    __recalibrate_iodelay_end(ret);
  • 0 in reply to Jeff Andich
    TI__Guru**** 170625 points

    Jeff,

    Per mine understanding, the "delta arrays" are specific for the AM572x device silicon revision (1.1 or 2.0). Thus when the board has AM572x SR1.1 device on it, core_padconf_array_delta_x15_sr1_1 is used, when the board has AM572x SR2.0 device on it, core_padconf_array_delta_x15_sr2_0 is used. Thus the code is more flexible, and support both silicon revisions (1.1 and 2.0).

    There are differences in the VOUT1 manual mode between SR1.1 and SR2.0. For more info refer to:

    www.ti.com/.../sprac44a.pdf - section 1.3.3 Manual Mode Example

    AM572x DM SR1.1 (SPRS915Q.pdf) and DM SR2.0 (SPRS953C.pdf).

    If you are planning to run your code on SR2.0 boards only, you can use one common array.



    Regards,
    Pavel

  • 0 in reply to Pavel Botev
    Intellectual 890 points
    Ok thank you! I THINK the cloud-based pinmux tool only generates pinmux output for SR2.0 now, correct?
  • 0 in reply to Jeff Andich
    TI__Guru**** 170625 points

    Jeff Andich said:
    I THINK the cloud-based pinmux tool only generates pinmux output for SR2.0 now, correct?

    Both AM5728 SR1.1 and SR2.0 are supported in the cloud-based pinmux tool. When you select "AM5728_SR2.0" device from the drop down menu, the tool will generate pinmux output for SR2.0 only.

    Regards,
    Pavel