DM8148 Uart5 issue

Ajay,

Please see this post for GPIO:

https://e2e.ti.com/support/dsp/davinci_digital_media_processors/int-dm814x/f/720/t/153934.aspx#557819

BR,

Viet

Viet Dinh said:

Ajay,

Please see this post for GPIO:

https://e2e.ti.com/support/dsp/davinci_digital_media_processors/int-dm814x/f/720/t/153934.aspx#557819

BR,

Viet

Viet,

Thanks for quick reply. But the link is not working. It says "Group Not Found". Can you please confirm link again?

Regards,
Ajay

Viet,

Thank you so much for updated link.

So mainly following is required to enable GP1[7:10] am I right?

          WR_MEM_32(MLBP_SIG_IO_CTRL_FOR_GPb7b8,   MLBP_SIG_IO_CTRL_VAL);                
          WR_MEM_32(MLBP_SIG_IO_CTRL_FOR_GPb9b10,  MLBP_SIG_IO_CTRL_VAL);

and in gel file all PINCNTL are loaded with same mux value

#define MUX_VAL                                     0x00040080

but according to 814x datasheet it should be different. Please correct me if I am wrong. I will get back after testing the GPIOs. what about UART5 pins? Do they have similar kind of control for it?

Regards,

Ajay Bhargav

Hi Viet,

Great news.. GP1[7:10] are working fine now :)

But I am still struggling to get UART5 to work. RXD and TXD pins are on multimux1 (Ball No. AA20 & AE21 respectively). I have configured PINCNTL135, 136 to MODE5 but I am unable to make uart work. Is there something specific to be done for UART lines just like GPIO?

Regards,

Ajay Bhargav

Hi Ajay,

You stated that your other UARTs are working fine, just UART5 is the not functional. The reset values of PINCNTL135/136 are 0x000E0000. When you set these to MODE5, the value is 0x000E0020. Thus you have pullup (PU) selected and enabled. This is done in bits [16] PLLUDEN = 0 (PU/PD enable) and [17] PLLTYPSEL = 1 (PU selected). What are the values in these bits 16 and 17 for your working UARTs?

Other thing that we can try is to use other MM mode than MM1. We can try with MM0 (PINCNTL243/244), MM2 (PINCNTL226/227) or MM3 (PINCNTL41/42).

Regards,

Pavel

Hi Pavel,

I have already configured uart5 in my mux configuration. But there seems to be some problem with muxing. I mounted debugfs to check if all mux configurations are done correctly or not I have found that uart5 muxing is not working. You can check this yourself by mounting debug fs. You will see the register values which are suppose to be 0xE0020 it shows as 0x0 which seems completely invalid.

Also there is something strange I have found in file "arch/arm/mach-omap2/devices.c" where uart5 pin is configured as video input. in function "ti81xx_video_mux"

omap_mux_init_signal("vin0_de0_mux0", OMAP_MUX_MODE0);
                /* force pin pad of  vin0_de0_mux0 to 0*/
                omap_writel(0, 0x48140A18);

why writing 0 to it? another silicon bug? and if you try to write even the default mode, you will not be able to set it.

For now I cannot use any other MM. I have to stick with MM1. Another thing I want to mention is, my RTS and CTS pins are on MM0 so Is it possible that uart will not work if RXD, TXD are on MM1 and RTS, CTS on MM0?

Thank & Regards,

Ajay Bhargav

hi Ajay,

This code in devices.c is strange for me also. I have check the DM814x Silicon Errata document, I did not find anything related to this.

First vin0_de0_mux0 is selected on the pin, right after this, 0 is written. And some lines below, vin0_de0_mux1 is selected, which means that vin0_de0 signal is routed in pin AB17.

vin0_fld0 signal is routed in MM0 (pin AA20) and some lines below the same signal is routed in MM1 (pin AC22).

What I can propose is to update arch/arm/mach-omap2/board-ti8148evm.c file as:

#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
    TI814X_MUX(VIN0_DE0_MUX0, OMAP_MUX_MODE5),    
    TI814X_MUX(VIN0_FLD0_MUX0, OMAP_MUX_MODE5),
    { .reg_offset = OMAP_MUX_TERMINATOR },
};

Then update arch/arm/mach-omap2/devices.c file as:

/*VIN0 configuraiton*/
        omap_mux_init_signal("vin0_clk1", TI814X_PULL_DIS | TI814X_INPUT_EN);
        //omap_mux_init_signal("vin0_de0_mux0", OMAP_MUX_MODE0);
        /* force pin pad of  vin0_de0_mux0 to 0*/
        //omap_writel(0, 0x48140A18);
        //omap_mux_init_signal("vin0_fld0_mux0", TI814X_PULL_DIS | TI814X_INPUT_EN);
        omap_mux_init_signal("vin0_clk0", TI814X_PULL_DIS | TI814X_INPUT_EN);

Thus when I check these signals from the user space, after the kernel boots, I have the following settings:

PINCNTL164 (0x48140A8C) = 0x00050001 - vin0_de0 selected
PINCNTL166 (0x48140A94) = 0x00050001 - vin0_fld0 selected
PINCNTL135 (0x48140A18) = 0x00000020 - uart5_txd selected
PINCNTL136 (0x48140A1C) = 0x00000020 - uart5_rxd selected

Does this work for you?

BR

Pavel

Hi Pavel,

Thank you for update. I have already tested it but no success. I dont know how you got these values in those registers. These are my findings:

commented code as you mentioned in devices.c

//omap_mux_init_signal("vin0_de0_mux0", OMAP_MUX_MODE0);
/* force pin pad of  vin0_de0_mux0 to 0*/
//omap_writel(0, 0x48140A18);
//omap_mux_init_signal("vin0_fld0_mux0",
//              TI814X_PULL_DIS | TI814X_INPUT_EN);

mux configured in board file:

TI814X_MUX(VIN0_DE0_MUX0, OMAP_MUX_MODE5),
TI814X_MUX(VIN0_FLD0_MUX0, OMAP_MUX_MODE5),

After kernel is up I checked muxing as follows:

# mount -t debugfs none /sys/kernel/debug/
# cat /sys/kernel/debug/omap_mux/vin0_de0_mux0
name: vin0_de0_mux0.(null) (0x48140a18/0xa18 = 0x0000), b NA, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0
signals: vin0_de0_mux0 | NA | NA | NA | vin0_hsync1 | uart5_txd_mux1 | i2c2_sda_mux1 | gpio2_0
# cat /sys/kernel/debug/omap_mux/vin0_fld0_mux0
name: vin0_fld0_mux0.vin0_fld0_mux0 (0x48140a1c/0xa1c = 0x50001), b NA, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE1
signals: vin0_fld0_mux0 | NA | NA | NA | vin0_vsync1 | uart5_rxd_mux1 | i2c2_scl_mux3 | gpio2_1

I have no idea why I am getting output like this... I do not find any other place where these registers are getting configured. and I think you need to configure FLD0_MUX0 as input coz its RXD of uart5.

TI814X_MUX(VIN0_FLD0_MUX0, OMAP_MUX_MODE5 | TI814X_INPUT_EN),

how did you confirmed muxing? as you see I am not getting the right values.

Regards,
Ajay Bhargav

hi Ajay,

I confirmed these value with our own executable file. But I tried with your method:

root@dm814x-evm:/# mount -t debugfs none /sys/kernel/debug/
root@dm814x-evm:/# cat /sys/kernel/debug/omap_mux/vin0_de0_mux0
name: vin0_de0_mux0.uart5_txd_mux1 (0x48140a18/0xa18 = 0x0020), b NA, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0
signals: vin0_de0_mux0 | NA | NA | NA | vin0_hsync1 | uart5_txd_mux1 | i2c2_sda_mux1 | gpio2_0
root@dm814x-evm:/# cat /sys/kernel/debug/omap_mux/vin0_fld0_mux0
name: vin0_fld0_mux0.uart5_rxd_mux1 (0x48140a1c/0xa1c = 0x0020), b NA, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0
signals: vin0_fld0_mux0 | NA | NA | NA | vin0_vsync1 | uart5_rxd_mux1 | i2c2_scl_mux3 | gpio2_1
root@dm814x-evm:/#

The result is the same. So it seems that we have differences in our kernels. Which EZSDK you are using? I am using EZSDK 5.04.00.11 with linux-2.6.37-psp04.04.00.01.

BR

Pavel

Hi Pavel,

I am using 5.03.01.15 older SDK and linux-2.6.37-psp04.01.00.06.patch2. But did PSP team changed anything on the muxing side? I have made lot of modifications in current psp so I have to see if with bare minimum I can get this new kernel work.

if possible please get a confirmation from PSP team if anything major changed in muxing side, and if there are patches available for psp04.01.00.06 to make things work.

Regards,

Ajay Bhargav

Hi Ajay,

I switch to the older EZSDK 5.03 with linux-2.6.37-psp04.01.00.06.patch2. And yes, I reproduced this bug. Also as you,  I do not find any other place where these registers are getting configured. I contacted the PSP team with these questions. I will get back to you when I have more info on that.

Best Regards,

Pavel

Hi Pavel,

Thank you so much for update. I tried new SDK today and I am able to see mux getting configured. But uart5 does work but its not working as expected.

I configured getty terminal on uart5

# getty 115200 ttyO5 &

but i get all garbage on screen. I thought its a baudrate issue even though it is suppose to work at 115200 baud. Then i tried different baudrates on receive terminal. but nothing happened, still the same garbage. Did you try sending/receiving data over uart5?

Regards,

Ajay Bhargav

hi Ajay,

To answer on one of your previous questions, the TXD/RXD on MM1 and CTS/RTS on MM0 is not a problem. I verify this with our Pin Mux Utility tool: http://processors.wiki.ti.com/index.php/Pin_Mux_Utility_for_ARM_MPU_Processors

According to this tool, the UART5 signals should be:

1. uart5_txd_mux1     O IEN IPU

2. uart5_rxd_mux1     I IEN IPU

3. uart5_cts_mux0     IO IEN IPD

4. uart5_rts_mux0      O IEN IPD

IEN - receiver enabled, IPU - internal pull-up, IPD - internal pull-down

Does your UART5 pins configuration match to the description above?

BR

Pavel

I am currently initializing my mux as follows:

omap_mux_init_signal("uart5_txd_mux1", TI814X_PULL_UP);
omap_mux_init_signal("uart5_rxd_mux1", TI814X_PULL_UP | TI814X_INPUT_EN);

i read the pin control registers as (readio is a user-space utility, I do not want to rely on just debugfs):

# ./readio 0x48140A1c w
/dev/mem opened.
Memory mapped at address 0x401a5000.
Value at address 0x48140A1C (0x401a5a1c): 0x60020
# ./readio 0x48140A18 w
/dev/mem opened.
Memory mapped at address 0x4031f000.
Value at address 0x48140A18 (0x4031fa18): 0x20020

muxing is working fine I believe, but on uart5 I am getting all garbage after I run

# getty 115200 ttyO5

is UART5 supported by serial driver?

Regards,

Ajay Bhargav

Hi Pavel,

could this be an issue with UART5 too as what I am receiving is complete junk?

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/190397.aspx

Regards,

Ajay Bhargav

Hi Pavel,

Thank you for code snippet. I know about changing the ref clock. For testing purpose I directly configured the required register from uboot and I am able to get Uart5 working perfectly fine.

But now my main problem is.. why muxing is not working on earlier SDK 5.03? Coz my current kernel porting is based on PSP v04.00.01.13. Did you get any reply from PSP team regarding muxing? Have they made any change in new SDK 5.04?

Regards,

Ajay Bhargav

hi Ajay,

After some investigation, I found that the UART5 mux settings are overwritten outside the linux kernel. They are overwritten from the HDVPSS firmware, file dm814x_hdvpss.xem3. When I comment this firmware loading in /targetfs/etc/init.d/load-hd-firmware.sh file:

echo "Loading HDVPSS Firmware"

# firmware_loader $HDVPSS_ID /usr/share/ti/ti-media-controller-utils/dm814x_hdvpss.xem3 start

The kernel reports some warnings about the VPSS, but finally boots. After that, reading the UART5 mux registers, the values are fine.

Does this fix work for you? If you need the HDVPSS firmware loading, I will continue with the investigation.

BR

Pavel

Hi Pavel,

I am sticking to latest SDK as everything works fine there. uart5 is working perfectly fine. I have changed parent clock for UART4, 5 & 6 to sysclk10.

I have found another bug in PSP4.04.00.01, this bug was already there in earlier PSP too. In structure uart5_fck and uart6_fck; clksel_mask was set to TI814X_UART3_MASK whereas it should be TI814X_UART4_MASK for uart5_fck and TI814X_UART5_MASK for uart6_fck. Please let PSP developer know about this.

Thanks & Regards,

Ajay Bhargav

Hi Ajay,

I will report this clksel_mask issue to the PSP team, thanks for the note. 

From what I understand, you are switching to the new PSP, where UART4/5/6 are working fine. So I am considering the UART5 mux issue as closed.

BR

Pavel

Hi Pavel,

Yes i moved to new PSP and making changes one by one so far everything is working fine except the SATA issue. Consider this issue as closed, coz even if vpss firmware is causing mux configuration to fail there is nothing I can do in that.

I will report if any more issues.

Thank & Regards,

Ajay Bhargav