Why GPIO0[27] is controlled by slaveloader?

Hello,

I tried to load the DSP/C674x firmware binary with the firmware loader (not the slave loader), and the GPIO0[27] PINCTRL202 register was not impacted.

Can you try loading the C674x firmware like this:

root@dm816x-evm:~# cd /usr/share/ti/ti-media-controller-utils/
root@dm816x-evm:/usr/share/ti/ti-media-controller-utils# ls
change_resolution.sh      dm816x_hdvpss.xem3        load-hd-v4l2-firmware.sh
dm816x_c6xdsp.xe674       dm816x_hdvpss_v4l2.xem3
dm816x_hdvicp.xem3        load-hd-firmware.sh
root@dm816x-evm:/usr/share/ti/ti-media-controller-utils# firmware_loader 0 dm816x_c6xdsp.xe674 start

The below link explains the difference between slave loader and firmware loader regarding EZSDK:

http://processors.wiki.ti.com/index.php/EZ_SDK_FAQ#What_is_the_difference_between_slave_loader_and_firmware_loader.3F

Regards,

Pavel

Hi Pavel,

I tried firmware loader but it is same.

But I found if I loaded C674x firmware in advance of setup VPSS library sysfs attributes (e.g. echo 65000,1024/300/20/72,768/36/2/1,1 > /sys/devices/platform/vpss/display1/timings), it is OK.

And both firmware loader and slave loader is same. But we don't know why it occurs.

Best regards,

Jed

Hi Jed,

I am using EZSDK 5.05.02.00 and DSP firmware loader does not change the GPIO0[27] pin value. Here is the log:

dm816x-evm login: root
root@dm816x-evm:~# ./readmem 0x48140B24
0x00000002
root@dm816x-evm:~#  cd /usr/share/ti/ti-media-controller-utils/
root@dm816x-evm:/usr/share/ti/ti-media-controller-utils# firmware_loader 0 dm816x_c6xdsp.xe674 start
FIRMWARE: I2cInit will be done by M3
FIRMWARE: Memory map bin file not passed
Usage : firmware_loader <Processor Id> <Location of Firmware> <start|stop> [-mmap <memory_map_file>] [-i2c <0|1>]
===Mandatory arguments===
<Processor Id>         0: DSP, 1: Video-M3, 2: Vpss-M3
<Location of Firmware> firmware binary file
<start|stop>           to start/stop the firmware
===Optional arguments===
-mmap                  input memory map bin file name
-i2c                   0: i2c init not done by M3, 1(default): i2c init done by M3
FIRMWARE: isI2cInitRequiredOnM3: 1
FIRMWARE: Default memory configuration is used
Firmware Loader debugging not configured
Default FL_DEBUG: warning
Allowed FL_DEBUG levels: error, warning, info, debug, log
MemCfg: DCMM (Dynamically Configurable Memory Map) Version :  2.1.2.1
FIRMWARE: 0 start Successful
root@dm816x-evm:/usr/share/ti/ti-media-controller-utils# cd
root@dm816x-evm:~# ./readmem 0x48140B24
0x00000002
root@dm816x-evm:~#

As you can see, the value of PINCTRL202[2:0] MUXMODE is 0x2 (GP0[27]) before and after loading the DSP firmware.

The PINCTRL202[2:0] MUXMODE can be set to 0x2 (GP0[27]) from the below file:

ti-ezsdk_dm816x-evm_5_05_02_00/board-support/linux-2.6.37-psp04.04.00.01/arch/arm/mach-omap2/board-ti8168evm.c

#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {

    /* PIN mux for non-muxed NOR */
    TI816X_MUX(TIM7_OUT, OMAP_MUX_MODE1),    /* gpmc_a12 */
    TI816X_MUX(UART1_CTSN, OMAP_MUX_MODE1),    /* gpmc_a13 */
    TI816X_MUX(UART1_RTSN, OMAP_MUX_MODE1),    /* gpmc_a14 */
    TI816X_MUX(UART2_RTSN, OMAP_MUX_MODE1),    /* gpmc_a15 */
    /* REVISIT: why 2 lines configured as gpmc_a15 */
    TI816X_MUX(SC1_RST, OMAP_MUX_MODE1),    /* gpmc_a15 */
    TI816X_MUX(UART2_CTSN, OMAP_MUX_MODE1),    /* gpmc_a16 */
    TI816X_MUX(UART0_RIN, OMAP_MUX_MODE1),    /* gpmc_a17 */
    TI816X_MUX(UART0_DCDN, OMAP_MUX_MODE1),    /* gpmc_a18 */
    TI816X_MUX(UART0_DSRN, OMAP_MUX_MODE1),    /* gpmc_a19 */
    TI816X_MUX(UART0_DTRN, OMAP_MUX_MODE1),    /* gpmc_a20 */
    TI816X_MUX(SPI_SCS3, OMAP_MUX_MODE1),    /* gpmc_a21 */
    TI816X_MUX(SPI_SCS2, OMAP_MUX_MODE1),    /* gpmc_a22 */
    TI816X_MUX(GP0_IO6, OMAP_MUX_MODE2),    /* gpmc_a23 */
    TI816X_MUX(TIM6_OUT, OMAP_MUX_MODE1),    /* gpmc-a24 */
    TI816X_MUX(SC0_DATA, OMAP_MUX_MODE1),    /* gpmc_a25 */
    /* for controlling high address */
    TI816X_MUX(GPMC_A27, OMAP_MUX_MODE1),    /* gpio-20 */
    TI816X_MUX(SC1_VPPEN, OMAP_MUX_MODE2),
    { .reg_offset = OMAP_MUX_TERMINATOR },
};

Regards,

Pavel

HI Pavel,

The PINCTRL202 Register (0x48140B24) is for PINMUX mode control, what I mean is not the PINMUX mode, it is the GPIO output value.

We want to output high level but once firmware loader/slave loader runs, GPIO0[27] will output low level.

Sorry for confusion.

Best regards,

Jed

Hi Jed,

Did you try with the latest EZSDK 5.05.02.00? Does this problem still exist in EZSDK 5.05.02.00?

Check also our GPIO driver User guide, where we have info how to control the GPIO output value:

http://processors.wiki.ti.com/index.php/TI81XX_PSP_GPIO_Driver_User_Guide

Regards,

Pavel

Hi Pavel,

I'm sorry that our HW engineer made a mistake that it is TIM4_OUT/GP0[28] pin which was impacted by slaveloaer/firmware_loader.

We config this pin as TIM4_OUT to generate PWM signal, but it seems that timer4 registers were flushed by slaveloaer/firmware_loader, the PWM signal was pulldown to low level once slaveloaer/firmware_loader is invoked, but the PINCTRL203 Register (0x48140B28) was not impacted.

Thanks again for your warmly help.

Best Regards,

Jed