OMAP138 LCDC from UBL

Have you made sure to enable the LCD pins in the SYSCFG pinmuxing registers? I didn't see that being done in your code.

Can you also do a readback verify of some of the data in the frame buffer to make sure the DDR is initialized and working at that point in the boot?

Jeff

Sorry, took me some time to see your reply. I was expecting a mail when someone replied to my post.

The PINMUX och DDR are setup earlier during the boot.

I have checked the PINMUX but here is the code relevant for LCD:

// PINMUX16: LCD D[2:7], NC, NC
DEVICE_pinmuxControl(16,0xFFFFFFFF,0x22222280);
// PINMUX17: LCD D[10:15], LCD D[0:1]
DEVICE_pinmuxControl(17,0xFFFFFFFF,0x22222222);
// PINMUX18: LCD RESET, LCD PCLK, NC, NC, NC, NC, LCD D[8:9]
DEVICE_pinmuxControl(18,0xFFFFFFFF,0x82888822);
// PINMUX19: RTCK, NC, NC, NC, NC, NC, LCD VSYNC, LCD HSYNC
DEVICE_pinmuxControl(19,0xFFFFFFFF,0x08888822);

I did a complete readback of my framebuffer and printed it on the serial console using:

framebuffer = (unsigned short*)0xC1F00000;
for (i = 0; i < 320 * 240 + 16; i++)
{
   n = 0;
   if ((i & 7) == 0)
   {
      str[n] = '\r'; n++;
      str[n] = '\n'; n++;
   }
   str[n] = (char)((*framebuffer >> 12) & 0xF);
   str[n] += (str[n] >= 10 ? 'A'-10 : '0'); n++;
   str[n] = (char)((*framebuffer >> 8) & 0xF);
   str[n] += (str[n] >= 10 ? 'A'-10 : '0'); n++;
   str[n] = (char)((*framebuffer >> 4) & 0xF);
   str[n] += (str[n] >= 10 ? 'A'-10 : '0'); n++;
   str[n] = (char)((*framebuffer >> 0) & 0xF);
   str[n] += (str[n] >= 10 ? 'A'-10 : '0'); n++;
   str[n] = ' '; n++;
   str[n] = '\0';
   DEBUG_printString(str);
   framebuffer++;
}

The data on the serial port seemed right and when I converted it back to an image and opened in GIMP I got the picture I was expecting.

Daniel

So are you saying the same code works after Linux has booted, but doesn't work when run as part of the UBL? Once Linux has finished booting does the display automatically start working or do you have to rerun the code? If you have to rerun the code that indicates something is not getting set up or is getting overwritten during the boot process.

Jeff

It's not the same code after Linux has booted, after Linux has booted it is the da8xx-fb driver.

What is the same are the register values (almost all, not the data pointers and all LCDC interrupts are turned off in the UBL). What I mean is that since it's working in Linux the hardware works. Also after the UBL has setup the LCDC registers the correct pixel clock, hsync and vsync frequencies are generated (measured with oscilloscope), but the screen is blank (data lines are not toggling at all).

To me it seems the LCD controller either isn't reading the framebuffer data or not having the data output on the data lines. I have run out of ideas of what to check.

What I am trying to do is setup the LCDC in the UBL to output the same picture over and over without any intervention from the CPU after it has been setup. Then I want to continue booting U-boot and Linux and not until Linux driver takes over should the picture change.

Can you check to make sure the PLL settings used for your UBL are identical to what is set up in Linux? You should be able to do this through CCS by checking the corresponding SYSCFG registers both when the UBL is running and then when Linux is running.

Also, if you have the OMAP-L138 EVM, the board support library has stand alone sample code for CCS which could be used directly for displaying LCD images. Is that a possibility for you to try?

Jeff

Hi, Daniel

it seems you are doing crazy  thing by the ubl.

im going to do the same work and would you please send your patch here or zanget@163.com if you dont mind :)???

thinks a lot.

regards, Mike