Mity CPU Platforms » MitySOM-AM57X

If the DSP is going to be controlling the UART, then UART5 will need to be disabled in the kernels device tree. Otherwise the ARM and DSP may both try to control the same hardware.

I will look into the UART example. I would have expected it to already have the code needed to configure baud rate and set up clocks.

Hello Jonathan,
Thank you for the reply.
I was under the impression that I need to make the device tree entry also.

So, I will have a look at the uart example app the baud rate and clock settings.
I my doubts are listed below
1. For the uart5 pins to get enabled, rebuilding the pdk with new pin mix files is enough?
2. How can we change the Uart instance in the example code and while changing the uart instance, the memory map will also get updated? If no, how can we do that?

Thanks in advance

Arun,

We don't have first-hand experience with this particular demo. We can look into it but it will take some time. In the meantime, you might want to submit an E2E question. There could be someone at TI who does have first-hand experience with this demo that may be able to help quicker.

Thanks.

Hello John,

Sorry for the delayed response. I have posted a similar question on E2E regarding the memory mapping on boards other than TI's idk, they have advised to take the support from the board manufacturer. I will again submit a question on E2E regarding changing the UART instance/updating memory map of the peripheral.

It will be great if you can provide a hello world example on wiki page. I know you have already provided a wiki page for adding ipc, but to make use of that we need to access a peripheral from DSP.

Regards,
Arun

Arun Krishnan wrote in RE: Hello World on DSP:

Hello Jonathan,
Thank you for the reply.
I was under the impression that I need to make the device tree entry also.

So, I will have a look at the uart example app the baud rate and clock settings.

Can you share the path to the uart example app?

I my doubts are listed below
1. For the uart5 pins to get enabled, rebuilding the pdk with new pin mux files is enough?

The pinmux should be set up by u-boot, there should be no need to touch the pinmux in the DSP. There is a wiki page, on how to configure the pinmux in u-boot. https://support.criticallink.com/redmine/projects/mitysom_am57x/wiki/U-Boot_Setup_Pinmux

2. How can we change the Uart instance in the example code and while changing the uart instance, the memory map will also get updated? If no, how can we do that?

Changing the UART instance, has to change the memory locations the TI UART driver is using. If it doesn't, then it would be a bug with their provided driver. There does appear to be lots of references to UART5 in the RTOS SDK source, including in some DRA7 and am57 header files, so I'd be surprised if it didn't work.

We currently don't have the time to create a UART hello world example for the DSP. However, if you had some code you could share, we could review it.

Hello Jonathan,
Thank you for the reply.

I was under the impression that I need to make the device tree entry also.

So, I will have a look at the uart example app the baud rate and clock settings.

Can you share the path to the uart example app?

The path for uart example app - sdk_rtos/pdk_am57xx_1_0_17/packages/MyExampleProjects/UART_BasicExample_idkAM574x_c66xExampleProject

I my doubts are listed below
1. For the uart5 pins to get enabled, rebuilding the pdk with new pin mux files is enough?

The pinmux should be set up by u-boot, there should be no need to touch the pinmux in the DSP. There is a wiki page, on how to configure the pinmux in u-boot. https://support.criticallink.com/redmine/projects/mitysom_am57x/wiki/U-Boot_Setup_Pinmux

OK, I will check this

2. How can we change the Uart instance in the example code and while changing the uart instance, the memory map will also get updated? If no, how can we do that?

Changing the UART instance, has to change the memory locations the TI UART driver is using. If it doesn't, then it would be a bug with their provided driver. There does appear to be lots of references to UART5 in the RTOS SDK source, including in some DRA7 and am57 header files, so I'd be surprised if it didn't work.

I will have a look at this

We currently don't have the time to create a UART hello world example for the DSP. However, if you had some code you could share, we could review it.

I will check the above 2 points and will share the example after that.

The pinmux should be set up by u-boot, there should be no need to touch the pinmux in the DSP. There is a wiki page, on how to configure the pinmux in u-boot. https://support.criticallink.com/redmine/projects/mitysom_am57x/wiki/U-Boot_Setup_Pinmux

This is applicable if we are have the Linus as OS. But if we running on RTOS on ARM core (without loading Linux), how we can do the the pin changes?

Changing the UART instance, has to change the memory locations the TI UART driver is using. If it doesn't, then it would be a bug with their provided driver. There does appear to be lots of references to UART5 in the RTOS SDK source, including in some DRA7 and am57 header files, so I'd be surprised if it didn't work.

Is that be enough?
If I want to change from UART3 to UART5, I can change the memory location from UART3 to UART5 by referring the L4_PER1 Memory Map of TI ref manual. (UART5_RXD is available in R6 ball as well as B19)
But, For eg: If I want to use the R6 pin (j11/17 in Devkit) as the UART5_RXD signal, I need to change the mux mode of GPMC_A0 pin to 8. How can I do this without using the U-boot (I mean w/o SD card)?

Hi Arun,

How are you loading the processor with the ARM RTOS and DSP RTOS? What boot media are you using, you said you aren't using sdcard? In my experience, we would boot into u-boot and then use u-boot to load the FPGA, DSP and ARM. It is possible to skip u-boot but as far as I know, we don't have any experience here doing that.

If we are going to be productive in helping, I think we need to start over. I need the bigger picture of your requirements and what you're trying to do.

Hello Jonathan,

My requirement is to use DSP to communicate with some of the peripherals and then use IPC for data transfer between Arm core and DSP core. II plant test the DSP without Linux first using using debug probe and then later modify this for Linux? Does this make sense?

Regards,
Arun

Arun Krishnan wrote in RE: Hello World on DSP:

Hello Jonathan,

My requirement is to use DSP to communicate with some of the peripherals and then use IPC for data transfer between Arm core and DSP core. II plant test the DSP without Linux first using using debug probe and then later modify this for Linux? Does this make sense?

Regards,
Arun

We don't have support for running the DSP barebones without u-boot or linux.

I'd recommend booting the SOM into Linux. You should still be able to connect to the DSP over JTAG and test your code without having to worry about the IPC communication but at least u-boot and Linux will have setup all the RAM, clocks, and pinmuxes. Adding all of that configuration to the DSP would need to be removed when you later tried to integrate it with Linux anyways.

AM57F devkit and want to use the pins UART5_TXD and UART5_RXD pins that are available as GPIOs in J11 (T9 and R6 pins).

To update the mux data in u-boot

diff --git a/board/cl/mitysom-57x/mux_data.h b/board/cl/mitysom-57x/mux_data.h
index d6928f064f0c..7d43574de78c 100644
--- a/board/cl/mitysom-57x/mux_data.h
+++ b/board/cl/mitysom-57x/mux_data.h
@@ -29,8 +29,8 @@ static const struct pad_conf_entry core_padconf_array_essential_mitysom_devkit[]
        {GPMC_AD13, (M0 | PIN_INPUT)},  /* J3 gpmc_ad13.gpmc_ad13 */
        {GPMC_AD14, (M0 | PIN_INPUT)},  /* H2 gpmc_ad14.gpmc_ad14 */
        {GPMC_AD15, (M0 | PIN_INPUT)},  /* H3 gpmc_ad15.gpmc_ad15 */
-       {GPMC_A0, (M14 | PIN_INPUT_PULLDOWN)},  /* R6 gpmc_a0.gpio7_3 J11.17 */
-       {GPMC_A1, (M14 | PIN_INPUT_PULLDOWN)},  /* T9 gpmc_a1.gpio7_4 J11.16 */
+       {GPMC_A0, (M8 | PIN_INPUT)},    /* R6 gpmc_a0.uart5_rxd J11.17 */
+       {GPMC_A1, (M8 | PIN_INPUT)},    /* T9 gpmc_a1.uart5_txd J11.16 */
        {GPMC_A2, (M14 | PIN_INPUT_PULLDOWN)},  /* T6 gpmc_a2.gpio7_5 J11.13 */
        {GPMC_A3, (M14 | PIN_INPUT_PULLDOWN)},  /* T7 gpmc_a3.gpio7_6 J11.11 */
        {GPMC_A4, (M7 | PIN_INPUT)},    /* P6 gpmc_a4.i2c5_scl */
@@ -304,8 +304,8 @@ static const struct pad_conf_entry core_padconf_array_essential_mitysom_nonfpga_
        {GPMC_AD13, (M14 | PIN_INPUT)}, /* J3 gpmc_ad13.gpio1_19 LA32_N SOM:sysboot_pulldown */
        {GPMC_AD14, (M14 | PIN_INPUT)}, /* H2 gpmc_ad14.gpio1_20 HA02_P SOM:sysboot_pulldown */
        {GPMC_AD15, (M14 | PIN_INPUT)}, /* H3 gpmc_ad15.gpio1_21 LA32_P SOM:sysboot_pullup */
-       {GPMC_A0, (M14 | PIN_INPUT_PULLDOWN)},  /* R6 gpmc_a0.gpio7_3 J11.17 */
-       {GPMC_A1, (M14 | PIN_INPUT_PULLDOWN)},  /* T9 gpmc_a1.gpio7_4 J11.16 */
+       {GPMC_A0, (M8 | PIN_INPUT)},    /* R6 gpmc_a0.uart5_rxd J11.17 */
+       {GPMC_A1, (M8 | PIN_INPUT)},    /* T9 gpmc_a1.uart5_txd J11.16 */
        {GPMC_A2, (M14 | PIN_INPUT_PULLDOWN)},  /* T6 gpmc_a2.gpio7_5 J11.13 */
        {GPMC_A3, (M14 | PIN_INPUT_PULLDOWN)},  /* T7 gpmc_a3.gpio7_6 J11.11 */
        {GPMC_A4, (M7 | PIN_INPUT)},    /* P6 gpmc_a4.i2c5_scl */

Hello Jonathan,

Thank you for the reply. I will check and get back to you.