The mipi screen can display the logo on the kernel, but the u-boot cannot display the logo.

The mipi screen can display the logo on the kernel, but the u-boot cannot display the logo.

Platform: rk3288

U-boot version: u-boot-2014.10

Kernel version: 3.10

Mipi screen model: LQ079L1SX01

Author: fulinux

* ***** This article allows reprinting, but please note the Source: http://blog.csdn.net/fulinus ****

Problem:

The use of the mipi screen can display the logo in the kernel, but the kernel can display.

Analysis:

If the kernel can be used normally, it indicates that the hardware is correct. The kernel and u-boot use the same device tree described in the dts file, so the information in the dts file should be correct. This is probably due to the MITI communication problem of u-boot.

Process:

After many debugging, we added an rk32_dsi_enable function to the probe function of the initialization of the mipi screen in the kernel. In this way, we put the logo that we originally needed to display in the u-boot:

It is displayed. Seize this opportunity to gradually block the rk32_dsi_enable function and find a key problem. After comparing the work done by u-boot, we found that the u-boot's mipi initialization did not send the initialization command, so I added the following code in u-boot to force the following command to be sent to the mipi controller:

Cmds [0] = LPDT;
Cmds [1] = 0x05;
Cmds [2] = 0x11;
Dsi_send_packet (0, cmds, 3 );
Dsi_send_packet (1, cmds, 3 );

Cmds [0] = LPDT;
Cmds [1] = 0x15;
Cmds [2] = 0x51;
Cmds [3] = 0xff;
Dsi_send_packet (0, cmds, 4 );
Dsi_send_packet (1, cmds, 4 );


Cmds [0] = LPDT;
Cmds [1] = 0x15;
Cmds [2] = 0x55;
Cmds [3] = 0x02;
Dsi_send_packet (0, cmds, 4 );
Dsi_send_packet (1, cmds, 4 );


Cmds [0] = LPDT;
Cmds [1] = 0x15;
Cmds [2] = 0x53;
Cmds [3] = 0x2c;
Dsi_send_packet (0, cmds, 4 );
Dsi_send_packet (1, cmds, 4 );


Cmds [0] = LPDT;
Cmds [1] = 0x05;
Cmds [2] = 0x29;
Dsi_send_packet (0, cmds, 3 );
Dsi_send_packet (1, cmds, 3 );

Sure enough. OK. These commands are the information in the data transmission file of mipi.

However, this code does not work, so the problem is further analyzed here:

List_for_each (screen_pos, & screen-> extract list_head ){

The list_head header is found to be empty, indicating that the information of the dts file is not parsed. The information of the dts file is parsed in:

In the rk_mipi_screen_init_dt function:

/* Get the initial command list */
Node = fdtdec_next_compatible (blob, 0, COMPAT_ROCKCHIP_MIPI_SONCMDS );
If (node <0 ){
MIPI_SCREEN_DBG ("Can not get node of COMPAT_ROCKCHIP_MIPI_SONCMDS \ n ");
} Else {
# If 1
Noffset = fdt_first_subnode (blob, node );
Const char * name = fdt_get_name (blob, noffset, NULL );
Printf ("XJH_DEBUG1: % s \ n", name );
Noffset = fdt_next_subnode (blob, noffset );
Const char * name1 = fdt_get_name (blob, noffset, NULL );
Printf ("XJH_DEBUG2: % s \ n", name1 );
# Endif
Printf ("fulinux mipi_oncmds 1 \ n ");
For (noffset = fdt_first_subnode (blob, node );
Noffset> = 0;
Noffset = fdt_next_subnode (blob, noffset )){
Printf ("fulinux mipi_oncmds 2 \ n ");
MIPI_SCREEN_DBG ("build mipi LCD init cmd tables \ n ");
Dcs_cmd = calloc (1, sizeof (struct mipi_dcs_cmd_ctr_list ));
Strcpy (dcs_cmd-> dcs_cmd.name, fdt_get_name (blob, noffset, NULL ));
MIPI_SCREEN_DBG ("% s \ n", dcs_cmd-> dcs_assist.name );


Dcs_cmd-> dcs_0000.type = fdtdec_get_int (blob, noffset, "rockchip, 1__type",-1 );
MIPI_SCREEN_DBG ("dcs_cmd.type = % 02x \ n", dcs_cmd-> dcs_cmd.type );


Dcs_cmd-> dcs_cmd.dsi_id = fdtdec_get_int (blob, noffset, "rockchip, dsi_id",-1 );
MIPI_SCREEN_DBG ("dcs_cmd.dsi_id = % 02x \ n", dcs_cmd-> dcs_cmd.dsi_id );


Fdt_getprop (blob, noffset, "rockchip, cmd", & length );
Dcs_cmd-> dcs_cmd.w._len = length/sizeof (u32 );
Err = fdtdec_get_int_array (blob, noffset, "rockchip, cmd", cmds, dcs_cmd-> dcs_cmd.cmd_len );
MIPI_SCREEN_DBG ("length = % d, pai_len = % d err = % d \ n", length, dcs_cmd-> dcs_cmd.cmd_len, err );


For (I = 0; I <(length/sizeof (u32); I ++ ){
MIPI_SCREEN_DBG ("cmd [% d] = 0x % 08x,", I + 1, cmds [I]);
Dcs_cmd-> dcs_cmd.cmds [I] = cmds [I];
}
MIPI_SCREEN_DBG ("\ n ");


Dcs_cmd-> dcs_mirror.delay = fdtdec_get_int (blob, noffset, "rockchip, cmd_delay",-1 );
MIPI_SCREEN_DBG ("dcs_0000.delay = % d \ n", dcs_cmd-> dcs_0000.delay );


List_add_tail (& dcs_cmd-> list, & screen-> define list_head );
}
}
Return 0;

The log of u-boot shows that printf ("fulinux mipi_oncmds 2 \ n"); is not printed. However, the Code with similar functions is normal. It indicates that the problem occurs during dts parsing. Is there a problem with the format in the dts file? After repeated debugging and exploration, who pulled this sentence when entering the dts file of the mipi screen:

Compatible = "rockchip, screen-on-cmds ";

This problem tells us that the building is built step by step and cannot be skipped!