i.MX53 TVE Not Working Android 10.3.2

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX53 TVE Not Working Android 10.3.2

1,852 Views
Davros
Contributor III

Greetings Freescale community.

I am working on an Android target which is based on a i.MX53 Sabre platform.  It is running Android 10.3.2.  I am currently trying to get the TVout functionality to work, as the target is a media platform.

I have been referencing mostly the i.MX_Android_R10.3.2_User_Guide.html, section 4.4.1 TVout for the boot parameters.  I have adjusted these parameters to be as follows:

Kernel command line: init=/init console=ttymxc1,115200 androidboot.console=ttymxc1 androidboot.model=MC-2000 androidboot.revision=1.03 androidboot.serialno=1390000000000028 video=mxcdi0fb:RGB666,CIO2-WVGA ldb=di0 di0_primary pmem=32M,64M fbmem=10M gpu_nommu gpu_memory=64M video=mxcdi1fb:YUV444,TV-NTSC tve ethaddr=00:17:1a:f0:01:2f boot_sbmr=0x10042940 boot_mode=normal

The screen resolution defined for CIO2-WVGA is defined in the mx53_cio2.c platform file, as seen below:

static struct fb_videomode video_modes[] = {

    {

     "CIO2-WVGA", 60, 800, 480, 37037, 40, 40, 5, 5, 20, 10,

     FB_SYNC_CLK_LAT_FALL,

     FB_VMODE_NONINTERLACED,

    0,},

    {

     /* 800x480 @ 57 Hz , pixel clk @ 27MHz */

     "CLAA-WVGA", 57, 800, 480, 37037, 40, 60, 10, 10, 20, 10,

     FB_SYNC_CLK_LAT_FALL,

     FB_VMODE_NONINTERLACED,

     0,},

    {

    /* 1600x1200 @ 60 Hz 162M pixel clk*/

    "UXGA", 60, 1600, 1200, 6172,

    304, 64,

    1, 46,

    192, 3,

    FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT,

    FB_VMODE_NONINTERLACED,

    0,},

};

I can confirm this via the following:

# cd /sys/class/graphics/fb0

# cat modes

D:800x480p-60

From the User Guide, I then perform the following shell instructions:

# cd /sys/class/graphics/fb1

# echo D:720x480i-60 > mode

# echo 0 >blank

# echo 1 >blank

# setprop rw.VIDEO_TVOUT_DISPLAY 1

At this point I should be able to use the Gallery app to play a video, which should have output to the TV, which it does not, although it is being displayed to the main LCD display.  I have also tried to force the unblanking via the following:

# echo 0 >blank

This still has no affect.  Should Android go ahead and unblank the display?  What would keep it from doing so?

I know it is not "officially" supported, I made a temporary change to the 'tve.c' driver to obtain its input from the color bar generator, and not the Video data bus, and the color bars do show up on the TV, confirming the correct hardware impedance.

I have been able to obtain the following register dump during playback from the tve and ipu:

tve_com_conf_reg 0x106009

tve_cd_cont_reg 0x0

tve_int_cont_reg 0x7

tve_tst_mode_reg 0x0

tve_tvdac_cont_reg0 0x0

tve_tvdac_cont_reg1 0x0

tve_tvdac_cont_reg2 0x0

IPU_CONF =      0x000006E0

IDMAC_CONF =    0x0000002F

IDMAC_CHA_EN1 =         0x18800000

IDMAC_CHA_EN2 =         0x00000000

IDMAC_CHA_PRI1 =        0x18800001

IDMAC_CHA_PRI2 =        0x00000000

IDMAC_BAND_EN1 =        0x00000000

IDMAC_BAND_EN2 =        0x00000000

IPU_CHA_DB_MODE_SEL0 =  0x08000000

IPU_CHA_DB_MODE_SEL1 =  0x00000000

IPU_CHA_TRB_MODE_SEL0 =         0x10800000

IPU_CHA_TRB_MODE_SEL1 =         0x00000000

DMFC_WR_CHAN =  0x00000090

DMFC_WR_CHAN_DEF =      0x202020F6

DMFC_DP_CHAN =  0x00009694

DMFC_DP_CHAN_DEF =      0x2020F6F6

DMFC_IC_CTRL =  0x00000002

IPU_FS_PROC_FLOW1 =     0x00000000

IPU_FS_PROC_FLOW2 =     0x00000000

IPU_FS_PROC_FLOW3 =     0x00000000

IPU_FS_DISP_FLOW1 =     0x00000000

IPU VDI Regs =  0x00000000

IPU CM Regs =   0x000006E4

IPU IC Regs =   0x00000000

IPU IDMAC Regs =        0x0000002F

IPU DP Regs =   0x0000030D

IPU DC Regs =   0xFFFF0000

IPU DMFC Regs =         0x00200000

IPU DI0 Regs =  0x06300006

IPU DI1 Regs =  0x10300096

IPU SMFC Regs =         0x00000000

IPU CSI0 Regs =         0x00000000

IPU CSI1 Regs =         0x00000000

IPU CPMem =     0x00000000

IPU TPMem =     0x00000000

IPU DC Template Mem =   0x00018808

IPU Display Region 1 Mem =      0x00000000

I am a bit concerned that the IDMAC_CHA_EN2 register seems to be un-initialized, although from the IPU_CONF, both display interfaces seem to be enabled.

I have looked at the Linux_20201112_20patch_bundle.tar.gz kernel patches, and this version of Android Linux seems to have all of these patches applied.

This is where it stands at this point.  If anyone has any ideas or suggestions, please let me know.

Labels (5)
0 Kudos
11 Replies

1,170 Views
lily_zhang
NXP Employee
NXP Employee

MX53 SMD boar does't have TVOut. But TVOut was supported on MX51 BBG.

In early time, we tested TVOut feature based on r10.3.2 on MX51 BBG. One trial is to change overlay hal to use v4l output rendering instead of framebuffer rendering to avoid video distortion issue on PAL TVOut. The UI and video show correctly on PAL TVout.

The updated changes are as following:

diff --git a/liboverlay/Android.mk b/liboverlay/Android.mk

index 1382262..026e63f 100755

--- a/liboverlay/Android.mk

+++ b/liboverlay/Android.mk

@@ -42,7 +42,7 @@ LOCAL_C_INCLUDES := \

LOCAL_MODULE := overlay.$(TARGET_BOARD_PLATFORM)

LOCAL_CFLAGS:= -DPMEM_ALLOCATOR -DMULTI_INSTANCES -DOVERLAY_DEBUG_LOGxx

-# LOCAL_CFLAGS += -DOVERLAY_V4L_OUT

+LOCAL_CFLAGS += -DOVERLAY_V4L_OUT

LOCAL_MODULE_TAGS := eng

Test steps on MX51 BBG:

1)       Set kernel command line to ‘console=ttymxc0 init=/init androidboot.console=ttymxc0 pmem=32M,64M fbmem=10M gpu_memory=32M video=mxcdi0fb:RGB24,640x480M@60,int_clk video=mxcdi1fb:YUV444,TV-PAL tve’

2)       Bootup the board and do ‘setprop rw.SECOND_DISPLAY_CONNECTED 1’ in console.

3)       Operate on UI to play a video.

Please try and let us know the result.

0 Kudos

1,170 Views
Davros
Contributor III

Many thanks for responding.  I have looked into this, and I have discovered the following:

The "LOCAL_CFLAGS += -DOVERLAY_V4L_OUT" was already being set in the build I was using, so this is good to go.

As far as the kernel parameters go, the "video=mxcdi0fb:RGB24,640x480M@60" parameter would cause nothing to be shown up on the main display, it would only be a grey screen.  This target seems finicky on the main display parameters.  By using the following, the main display would actually display:  "video=mxcdi0fb:RGB666,CIO2-WVGA".  However I did add the internal clock reference flag "int_clk", so the parameter ended up being as follows, "video=mxcdi0fb:RGB666,CIO2-WVGA,int_clk".

After bootup and the main display working, I then would perform the following command via the shell prompt:  "setprop rw.SECOND_DISPLAY_CONNECTED 1".  After a few seconds, I could see the frame buffer events being sent to the tve.c driver.  The "MODE CHANGE" event for the "DISP3 BG - DI1", which seems to key actually to actually switching on the tve driver.  This exits without error, however I now notice the mxc_ipu driver generates two error interrupts occuring:


mxc_ipu mxc_ipu: IPU Error - IPU_INT_STAT_5 = 0x00800000

mxc_ipu mxc_ipu: IPU Error - IPU_INT_STAT_10 = 0x00100000

The first error indicates IDMAC_NFB4EOF_ERROR_23.  I am unsure what this actually means. 

The second error is DI1_SYNC_DISP_ERR, seems to be a result of an error during access to a synchronous display via DI1.  This might seem more of where the problem is, although I am unsure specifically what this would mean.

While the main display would work, it would "blank out" when actually playing a video file, indicating no video being rendered there.  However a touch to the display screen would bring up the progress bar, indicating the graphics layer was still running okay.  However no video being displayed on the TVout, which might be related to the error occurring above.  It would also appear that the video clip is actually be rendered for I can hear the audio via the TV.

Many thanks for your help!

0 Kudos

1,170 Views
lily_zhang
NXP Employee
NXP Employee

The example command line is based on MX51 BBG. Please change it according for you MX53 board. Please share your full boot command line and the complete log. So we can give the comments.

Lily

0 Kudos

1,170 Views
Davros
Contributor III

Can do, and here it is.

Kernel command line: init=/init console=ttymxc1,115200 androidboot.console=ttymxc1 androidboot.model=MC-2000 androidboot.revision=1.03 androidboot.serialno=1390000000000028 video=mxcdi0fb:RGB666,CIO2-WVGA,int_clk ldb=di0 di0_primary pmem=32M,64M fbmem=10M gpu_nommu gpu_memory=64M video=mxcdi1fb:YUV444,TV-PAL tve ethaddr=00:17:1a:f0:01:2f boot_sbmr=0x10042940 boot_mode=normal

Many thanks for your help.

Daryl

0 Kudos

1,170 Views
lily_zhang
NXP Employee
NXP Employee

Because you mention you are using dumb WVGA panel, suggest that you change “ldb=di0” as “ldb=off”.

0 Kudos

1,170 Views
Davros
Contributor III

Thanks for responding!!

This is somewhat of a positive change.  After reviewing the schematic, the LCD display is hooked to LVDS0 via an FPGA.  With this change, the main display will not work.

However, after doing the "setprop rw.SECOND_DISPLAY_CONNECTED 1", the component output is working great.  I am able to use the TV as a reference for the touch screen (from main display) in order to navigate Android, play content, etc. 

So, I must be missing something fundamental here, as both side work, but not together.  What could this be?

Many thanks!

0 Kudos

1,170 Views
lily_zhang
NXP Employee
NXP Employee

If you add ldb command option, it may lead LDB and TVE use the same clock source.

You can check your SW and use different clock source for LDB and TVE.


1,170 Views
Davros
Contributor III

Many thanks for your help!! I think I know where to proceed at this point.

0 Kudos

1,170 Views
daiane_angolini
NXP Employee
NXP Employee

when you test the color bar, what resolution do you use?

I did not understand why you are changing the output resolution:

# cd /sys/class/graphics/fb0

# cat modes

D:800x480p-60

From the User Guide, I then perform the following shell instructions:

# cd /sys/class/graphics/fb1

# echo D:720x480i-60 > mode

# echo 0 >blank

# echo 1 >blank

# setprop rw.VIDEO_TVOUT_DISPLAY 1

Other thing that I want to confirm. You mentioned you are right that your display was correct recognized by kernel because you can see fb0/modes your mode.

But, when you blank and unblank, you are acting over fb1

What fb are you working with?

0 Kudos

1,170 Views
Davros
Contributor III

Thank you for responding!!

Honestly, I am not sure what resolution the color bar was, I am assuming 720x480i.  To test, I simply unblanked FB1 (echo 0 > blank), then I had a hook which simply changed the DATA_SOURCE_SEL field in the TVE_COM_CONF_REG from 0 to 3.  Once I did this, color bars showed up on the external TV.

I am not trying to change resolution, but to just get TVout working.  The main lcd display is 800x480, which seem to be fb0.  The modes for fb1 are as follows:

# cd /sys/class/graphics/fb1

# cat modes

D:1920x1080p-24

D:1920x1080p-25

D:1920x1080p-30

D:1920x1080i-50

D:1920x1080i-60

D:1280x720p-30

D:1280x720p-60

D:720x576i-50

D:720x480i-60

I was choosing a resolution similar to the display but still in the NTSC signaling.

Yep, fb0 mode(s) (really only one mode) is as follows:

# cd /sys/class/graphics/fb0

# cat modes

D:800x480p-60

Yep, blank/unblank is on the fb1, again, I am presuming this is correct since seems to match up with the video_modes[] array in the tve.c driver.

Many thanks for your help!

0 Kudos

1,170 Views
daiane_angolini
NXP Employee
NXP Employee

Would you be able to test your kernel with a non-android rootfs? (I mean, a pure linux environment?)

You can make sure your kernel is OK and the issue is only a android configuration mistake.

0 Kudos