• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 446 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.

AM625: main uart1

John Tobias
Intellectual 345 points

Part Number: AM625

Tool/software:

Hi,

In our custom board we used the UART1 differently - we used it to talk to other device.

We did not disable the 'main_uart1' in u-boot R5 dtsi file, so every time the u-boot tispl.bin execute it configures the main_uart1.

&main_uart1 {
pinctrl-names = "default";
pinctrl-0 = <&main_uart1_pins_default>;
status = "okay";
bootph-pre-ram;
};

One of the pin in main_uart1_pins_default we used it for asserting the eMMC reset.

 

Then, in kernel dts file, we still have this setting below:

&main_uart1 {
/* Main UART1 is used by TIFS firmware */
status = "reserved";
};

For our custom board, used different pins/pinmux for UART1 - so it totally different from u-boot main_uart1_pins_default pins.

The board boots fine except when writing data in eMMC and do the TX in UART1. Every time I write in serial, it assert the eMMC reset pin then when I set the 'main_uart1' status to 'disabled' in u-boot R5, it fixed the issue.

I was trying to trace/understand how it accessed the u-boot 'main_uart1' (even thought the kernel main_uart1 configuration is totally differently from u-boot main_uart1 configuration?. Which one (kernel, tiffs, device management / sciserver) are the one accessing the u-boot main_uart1?

Regards,

John

  • 0
    TI__Guru**** 180756 points

    Hi John,

    Let's put the software aside, are you saying you routed a main UART1 pin to both eMMC reset pin and the UART connector on your board?

  • 0 in reply to Bin Liu
    Intellectual 345 points

    Hi Bin,

    No. We did not route it to both.

    Just to clarify, In am625-sk board r5 u-boot dtsi file the default UART1 configurations is this:

    main_uart1_pins_default: main-uart1-pins-default {
    pinctrl-single,pins = <
    AM62X_IOPAD(0x194, PIN_INPUT, 2) /* (B19) MCASP0_AXR3.UART1_CTSn */
    AM62X_IOPAD(0x198, PIN_OUTPUT, 2) /* (A19) MCASP0_AXR2.UART1_RTSn */
    AM62X_IOPAD(0x1ac, PIN_INPUT, 2) /* (E19) MCASP0_AFSR.UART1_RXD */
    AM62X_IOPAD(0x1b0, PIN_OUTPUT, 2) /* (A20) MCASP0_ACLKR.UART1_TXD */
    >;

    In our custom board designed we used the pin A20 as the eMMC reset pin and then for the UART1 we used pins B17 and A17 for RX and TX (we don't need CTS/RTS). Hardware wise, no conflict.

     

    As I mentioned in my first post, we didn't disable the 'main_uart1' in u-boot and the tispl.bin still configures it every time it loads the said image.

    Technically, If I send data to UART1 the A20 should not be asserted since my board is using pins B17/A17.

    But, somehow, there's a process asserting the A20 and I couldn't figure out which one.

  • 0 in reply to John Tobias
    TI__Guru**** 180756 points

    Hi John,

    Please attach both board device tree files from U-Boot and kernel, so that I can see how exactly the pinmux is set in both. Please attach the files and don't copy & paste them here, since the files are very long.