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.
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.
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!
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
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
Because you mention you are using dumb WVGA panel, suggest that you change “ldb=di0” as “ldb=off”.
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!
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.
Many thanks for your help!! I think I know where to proceed at this point.
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?
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!
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.