Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Mr. Schlunk,

The kernel included in the development kit provided should have the necessary code installed to support either the DVI interface or the LCD panel interface. To enable the display, the config options in uBoot must be updated to tell the kernel to initialize the device. When the kernel initializes the device, it will automatically create the /dev/fb driver interface. There is nothing to implement on your end. In addition, for the MityDSP-L138F and MityARM-1808F (modules with FPGAs populated), an FPGA load is needed to route the video signals from the OMAP-L138 to the module edge connector pins that mate to the LCD or the DVI chip/connector.

For the LCD, Critical Link does have a QVGA (and I also believe a QWVGA) panel with touchscreen available that would work with the interface. The QWVGA panel will require an update the linux kernel, which we can provide. If you want to design your own panel, you'll need to update the da8xx-fb.c file in the linux/drivers/video area of the kernel code to set the correct timings, etc. You'll need to contact Tom Catalino or someone in sales for details about that.

For the DVI, you must use a monitor that accepts true DVI inputs (you can't use a DVI to VGA adaptor cable, the signals are only digital).

We'll need to post the configuration instructions and the respective FPGA images (with code, so you can merge this with you custom IP). We've tested both interfaces, and we just need to pull together the code/scripts and get it on the wiki. If you know which path you'd like to head down I'll try to add that information first.

-Mike

I'll need a little more information about the uboot to be able to have it tell the kernel to initialize the device. Are we setting some environment variable here?

The LCD configuration wiki page has been started that will cover the information you need. It's a work in progress, but there should be enough info in there now to at least force a frame buffer device into existence for the kernel.

Could you put the link to that wiki page into the wiki start page please.

It's off the Das_U-Boot_Port page from the start page. I'll look at making another entry.

We'll take a look at this setup today and let you know what happens.

The next thing we'll want to know is what commands (ioctl, for example) are enabled on the dev/fb device. I assume that the device will have various "files" visible in /dev/fb/ that enable its functions, but when developing it's always helpful to have a description of what's implemented and what limitations it might have, so I can know if I'm barking up the wrong tree. At this point, all we really need to do is draw a bitmap to memory and have it show up on the LCD.

Thanks.

I downloaded the file "IndustrialIO_dvi_revA-B.bin" and used it to program the FPGA (in Linux, using the instructions from the Wiki). I then did the configuration commands found on the LCD configuration Wiki page. That seems to have gotten the low-level hardware to recognize things, since the U-Boot startup now says something like "configured LCD: vga_640x480" and I get a message in the system log saying "Found Device ID 01-TFP410 DVI Controller...".

However, I don't see a /dev/fb0 device. I've got a true DVI panel hooked to the unit, as required. I'm guessing that there's another step needed, at the Linux level. I'm researching that now and will post here again if I find it before someone else does.

Note: the DVI download image for the FPGA is in the section for the LCD on the Wiki; the name indicates it's for the DVI, so I'm going to assume it's the right FPGA image unless I'm told otherwise.

That's the right image. All the files show up at the bottom of the wiki.

I've updated the wiki with more instructions (they seem involved, but it's not that bad once you do it the first time), primarily with turning on the DVI controller (it comes up in a power savings mode). You need to do that with I2C through the FPGA (which is supported in the image we sent). I'll get the source up there as well.

I'll try to post more about the supported IOCTLs ASAP.

Sorry for the delay.

-Mike

Got it. I'll check this out right now and let you know what happens.

OK -- we're definitely making progress here. I now see a raster on the DVI-based monitor. It's just vertical blue stripes, but clearly something is driving a signal out to the display. Yes, the instructions are involved, but they're easy enough to follow.

Note: there's a minor/obvious typo in the instructions: it should say "/sys/devices/fpga_ctrl/" everywhere instead of "/sys/device/fpga_ctrl/".

I manually created the /dev/fb0 device, as instructed, since it wasn't there. Unfortunately, it gives me "Operation not permitted" errors whenever I try to read or write the device, so although it's there I can't change the image.

BTW, I programmed the FPGA with the DVI-specific image again, even though it was already in there, just to be sure.

So, now the question is what did I do wrong to cause the frame buffer to be non-readable and non-writable?

Thanks.

William
If you are seeing blue vertical stripes (every other pixel) then the frame buffer is working..
try the following command...
echo 0 > /sys/devices/platform/da8xx_lcdc.0/graphics/fb0/blank
If the screen shows a login prompt, then the display system is up and running.
You can also use the command
cat /proc/devices
and verify that the line
29 fb
is present under Character devices:

cheers
/Tim

Got it working. A few oddities, but I'm now able to at least talk to the frame buffer.

The screen is all blue and green. Not sure why I don't get any reds. But I won't be using DVI for my real demo, so that's not very critical. Quite possibly an error on my end.

I believe you've already posted the FPGA binary that supports your LCD panel, right? Any recent changes to that? I'll have the Critical Link-recommended panel here tomorrow and will start working with it then.

Our system never seems to create the /dev/fb0 device on startup. I've successfully used the instructions on the LCD Wiki page to create that device, so I'm able to work with it. Would be nice to get this more automated if we can figure out why it's not showing up, but again that's not a show-stopper.

Do you have a specific tool you know about for converting to RGB565 format? I was quite surprised to discover that my two favorite programs, Photoshop and ImageMagick, both don't export in that format, and apparently neither does Gimp. I can write something myself very easily, but thought I'd ask if you already know of something.

Thanks.

Can you please confirm the revision of your board (B, or C)?

Before you write to the /dev/fb0 device, do you see a linux prompt? Is the text white (you may need to poke the blank variable as mentioned above). I am concerned about the color scheme you are describing. We may not have the correct i2c settings posted on the wiki.

565 conversion isn't very popular, unfortunately we've had to write our own. If you use qt-embedded, it has a translator built in (to read png's, etc., and output 565 to the frame buffer).

I'll post the LCD image up there. It's not there yet.

Definitely not a Rev C board, so it must be a B (I think we have an A here as well, but this isn't it).

Yes, actually, we do see a Linux prompt and cursor on that screen. Text is blue and the penguin at the upper left is blue and green. Since we're not getting any red guns, no white pixels. My logo is grayscale on a white background, and the background is blue (could be blue-green; I didn't check that closely).

I hear there's a 565 converter in the Android development kit, so I'll probably try to use that one.

After you are up and running, could you please run a

i2cdump -y 2 0x38

and post or email me the results?

Thanks.

-Mike

Done. Here's what I see:

0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 4c 01 10 04 00 00 14 64 3f 06 80 00 a9 db 97 22    L???..?d???.???" 
10: 00 00 00 00 00 22 e1 5f ac b2 5c 48 41 00 00 00    ....."?_??\HA...
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
30: 00 00 00 30 00 00 00 00 00 00 14 03 e9 01 00 00    ...0......????..
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 07 0f 01 44 38 02 00 00 8e 02 00    .....???D8?..??.
e0: 00 00 00 00 38 00 04 00 00 00 00 00 00 00 00 00    ....8.?.........
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

BTW, we figured out how to do the bitmaps. It's really easy: Generate a BMP, turn it upside down, and save it as RGB565. Then trim off the first 72 bytes of the file. That's a RAW RGB565 file and it works fine on the dev kit.

I'm still seeing wrong colors, of course. What I mean is that the pixels are in the right places.

I added a simple test pattern generator to the wiki LCD_configuration. It draws a white box around the border of the frame buffer and fills it
with 16 bars. Each bar is one bit of color, so you should get 5 blue bars, 6 green bars, and 5 red bars. The compile command line is in the file header comment.

cheers
/Tim

Ah. OK. You punched in the i2c commands for the Rev C board. You have 0x3f programmed into position 0x08.

Please use the following two commands (as described in the wiki):

root@mityomapl138:~# i2cset -y 2 0x38 0x8 0xb9
root@mityomapl138:~# i2cset -y 2 0x38 0x33 0x30

I think that should get you the correct colors.

-Mike

Yup. That did it.

For some reason, I had copied the instructions for the Rev. C board instead of the ones above.

Test gradient looks fine now, and so does my logo.

Now we move on to installing the LCD panel (the one we got from you) and trying to get that working. Will I need separate instructions for creating the fb0 device for that component? If so, let me know. Otherwise, we'll ping you again when we have questions.

Thanks.

You'll need a different FPGA image. You also need to load an additional module (for the touchscreen controller on the LCD).

-Mike

We were able to get the LCD going with no problem, BTW. We'll be using it for our demo next week.

Thanks for the help.

The wiki lists vga_640x480 and Sharp_LQ035Q7DH06 as Displays that are known. The new version of the board we have been given has a
COM57H5M06XRC (TFT-LCD) attached. What should I set for "LCD Panel" in the UBoot?

Related Notes: just so you know, we have an FPGA binary which supports our new LCD panel, and it maps the memory for the LCD to the same location that's used for the current two Critical Link supported devices. So we'll be using our own FPGA.bin file, but the question is how to configure U-Boot and also what we need to do in Linux to be able to talk to that memory-mapped RAM.

We're in need of some information on this item because our primary assignment now is to implement our LCD functionality in the unit. When can we expect to receive feedback on this issue? Thanks.

Hi all,

If you have designed your own hardware using a new LCD, I'm afraid you're going to be on your own to get it functioning (unless you can provide schematics, your FPGA code, and some hardware for us to support you with). I can, however, point you to the relevant source code that you will need to modify to set the timings for the video portion, etc., for the LCD controller in the OMAP-L138. I don't know what you're using for the touchscreen interface ADC (controller, SPI interface, I2C interface, etc.).

In the linux kernel, you will need to modify the following 2 files:

• arch/arm/mach-davinci/board-mityomapl138.c

This file must be modified to call out a new LCD panel name that gets passed to the LCD device driver.

You will need to check the settings in the lcd_cfg structure, add a new da8xx_lcdc_platform_data structure for the COM57H5M06XRC, and update the mityomapl138_setup_lcd() in order to ensure that the platform_data points to the corresponding structure.

• drivers/video/da8xx-fb.c

In this file, you need to search for the known_lcd_panels[] array and add a new entry for the COM57H5M06XRC. This table defines the size of the panel as well as the desired pixel clock rate, front and back porches, etc., that must match the timing specifications for the panel. The "name" fields is keyed in the init code in the board-mityomapl138.c file.

Details regarding the LCD controller hardware in the OMAP are included at:

http://www.ti.com/litv/pdf/sprufm0b

Again, we can't really help too much here without detailed schematics, and ideally some hardware test with.

-Mike