Hi.
I've never used the Beagle Board before, but I'm very keen to use it in a project that I'm working on.
What I need is a small board (max. 80 x 100 mm) powerful enough to run some Linux GI (qtopia, Android,...), and, over this GI we will run a program still to be developed.
The Beagle Board, so far, looks to fit my needs, right?
The only "issue" that I'm having at this stage is to find a compatible 5.7" (or 5.6") LCD for it.
It doesn't, necessarily, has to have touch screen (it would be good, though 
).
It can't be other size LCD, as we will use a case that we've already got.
So.. Does anyone would know a source where I can purchase LCDs to fit my project?
Thanks.
Regards,
Mateus Ohse
Mateus:
I don't know about all LCDs which may be compatible with the
BeagleBoard, but there are ARM9 LPC3250 kits for 5.7 inch displays,
and they do run Linux.
http://www.teamfdi.com/development-tools-kits/products/1/DK-57VTS-LPC3250
Regards:
Mike Nelson, http://michaeltnelson.com
mobile: 1-650-291-7343
office: 1-650-257-7565
Mateus ohse <ozzy.dm@gmail.com> [2010-08-20 12:10:04]:
Hi.
Hi,
The only "issue" that I'm having at this stage is to find a compatible
5.7" (or 5.6") LCD for it.
It doesn't, necessarily, has to have touch screen (it would be good,
though ).
check vitrolight.com, they might have 5.6" or 5.7". But remember, that you'll
need to create some kind of adapter board, to convert the required logic
levels of the LCD panel you want use. All of the signals on the beagleboard
are 1.8V and the display will need usually 3.3V. And you will also need to
provide something to drive the backlight circuit also. Search the mailing list
archive, it's been asked here regularly.
-- ynezz
Any idea of a supplier for this conversion board?
Thanks
Mateus
Take a look at gumstix.
They are the same architecture as the beagleboard, and have a LCD screen kit.
http://www.gumstix.com/store/catalog/product_info.php?products_id=252
Regards,
Adam
That is pretty cool. Do you know if there’s support for that LCD in Linux kernel already or do folks tend to write their own driver for that LCD?
it is very easy to write your own driver for LCD. I will send you an example if you need
2010/8/21 Matt Causey <matt.causey@gmail.com>
Actually that’d be great. I’d love to learn from your example.
Could you, please?
I would very much appreciate. 
Thanks
Mateus
Can you post it for all the people in this group? Or push in the stable/2009 openembedded branch?
I would also really appreciate
By the way, what are the differences between DVI and LCD beside back-light control?
I think the sync-strobes should be the same and the data bus should not change.
Thanks
Fabio
Hi guys!
Just as I promissed the patch is attached.
Here is a little description…
This patch is for 3 different displays:
- Microtips MTF-T070ACSL 800x400 18bit RGB
- OSD 8" 800x600 18bit RGB
- OSD 10.2" 1024x600 LVDS
Both of the displays are connected in 18bit RGB mode. This means that only 18 bits from 24 are connected to displays. In case of 18bit displays you can have 2 options:
- connect upper 6bits for each color and to use software in 24bit mode. I believe OVERO is implemented so (in this mode memory consumption is more because lower bits are colored but not used)
- use low 18bits of DSS lines to feed a display as descibed at SPRUF98D p.2132. (no additional memory use, just what is colored)
All displays are connected to OMAP3530 based SODIMM module BlueShark and base-board Atoll-Deluxe. You can find additional info in Google.
So the software:
Main parts:
- arch/arm/mach-omap2/board-omap3beagle.c
- here you must add the following structures (one is explained):
static struct omap_dss_device blueshark_mtf7_device = {
.type = OMAP_DISPLAY_TYPE_DPI,
.name = “mtf7”,
.driver_name = “microtips_mtf7_panel”,
.phy.dpi.data_lines = 18,
.reset_gpio = BLUESHARK_GPIO_LCD_BL,
.platform_enable = blueshark_enable_disp,
.platform_disable = blueshark_disable_disp,
};
“name” - this is how the display will be called, I mean how you tell a kernel to use exactly this display, not DVI or other LCD.
“driver_name” - this is a name of the driver, it is identified in kernel
“.phy.dpi.data_lines” - this is how you define 18bits or 24bits for DSS lines actually used. From here DSS driver will setup correctly the LCD controller.
“reset_gpio” - you can define a line for LCD back light driving line
platform_enable/paltform_disable - functions which turn on and off a display
- Add above structures to “blueshark_dss_devices” structure so the kernel could find the requested driver amoung represented.
static struct omap_dss_device *blueshark_dss_devices[] = {
&blueshark_dvi_device,
&blueshark_tv_device,
+#if defined(CONFIG_PANEL_MTF7) || defined(CONFIG_PANEL_MTF7_MODULE)
- &blueshark_mtf7_device,
+#endif
- setup GPIO for LCD B/L if you need
-
drivers/video/omap2/displays/Kconfig
In this file you add a config variable which you can enable or disable during “make menuconfig” for a kernel
-
drivers/video/omap2/displays/Makefile
add object names for you files which contain drivers
-
drivers/video/omap2/displays/panel-mtf7.c or a different name
here you write you driver. The main part of this code is the structure:
static struct omap_video_timings mtf7_timings = {
- .x_res = 800,
- .y_res = 480,
blueshark-dss.patch (13.3 KB)
Maxim Podbereznyy wrote:
Hi guys!
Just as I promissed the patch is attached.
Here is a little description..
This patch is for 3 different displays:
1) Microtips MTF-T070ACSL 800x400 18bit RGB
2) OSD 8" 800x600 18bit RGB
3) OSD 10.2" 1024x600 LVDS
Both of the displays are connected in 18bit RGB mode. This means that
only 18 bits from 24 are connected to displays. In case of 18bit
displays you can have 2 options:
1) connect upper 6bits for each color and to use software in 24bit mode.
I believe OVERO is implemented so (in this mode memory consumption is
more because lower bits are colored but not used)
no, data is still 32bit in memory (is there a 24bit packed mode?) and only
18/24 bits are sent to the display. There is no memory to be gained by using
an 18bit only display...
2) use low 18bits of DSS lines to feed a display as descibed at SPRUF98D
p.2132. (no additional memory use, just what is colored)
see above.
the advantage of 2) is more that in this mode you can use the DSS2
built-in dithering to improve the visual quality for images and videos.
Hi Vladimir,
I guess you are right!
Max
2010/8/24 Vladimir Pantelic <vladoman@gmail.com>
This is very helpful info! I'm looking at your hardware, I presume
it's like this one:
http://www.mentorel.com/sbc-9263v2.html
Is that correct?
I looked on Mouser to find T070ACSL that you're using and it looks
like it's a 40 pin interface off the LCD?
I'm using BeagleBoard with the hy-research expansion board. The LCD
is a 45 pin into the expansion board from the LCD.
Given that my hardware is slightly different should the same driver
methodology still work for my hardware? I suspect that it should and
will be using your example to create one just to try....but wanted to
see if you had any insights there.
Matt,
No! this one
mentorel.com/blueshark.html
mentorel.com/atoll.html
Indeed T070ACSL has 40 pin interface but I use different adapter boards for my Eval-kit and can connect almost any display anyone can imagine.
All displays are the same in general, just different arrangment of LCD/power pins. Of course, the driver sources I have provided are fit to any of displays. In some cases driving a display requires some additional steps like setting RESET line or INIT (Sharp LS037V7DW01). Hope you don’t need this for your display. Anyway you can look for the implementation of these additional steps in drivers/video/omap2/displays/panel-… for the Sharp display.
any questions - ask!
Max
2010/8/25 Matt Causey <matt.causey@gmail.com>
Hi Max,
It's taken me some time to digest the patch you provided, and all the
detailed info. I've another question now.
I'm basically working through your patch to learn the process. I'm
working with Beagle, ultimately but I can see how similar the config
is now. Here's a snippet from your patch
(arch/arm/mach-omap2/board-blueshark.c):
@@ -703,6 +750,10 @@
gpio_request(170, "DVI_nPD");
/* REVISIT leave DVI powered down until it's needed ... */
gpio_direction_output(170, true);
+ /* LCD backlight turn off */
+ omap_mux_init_gpio(BLUESHARK_GPIO_LCD_BL, OMAP_PIN_INPUT);
+ gpio_request(BLUESHARK_GPIO_LCD_BL, "LCD_BL");
+ gpio_direction_output(BLUESHARK_GPIO_LCD_BL, 0);
So I got this patch applied for the most part, but now I see that
omap_mux_init_gpio() is not defined, so the kernel fails to compile.
It's defined in 2.6.33:
http://lxr.free-electrons.com/source/arch/arm/mach-omap2/mux.c?v=2.6.33;a=arm#L380
but not 2.6.32:
http://lxr.free-electrons.com/source/arch/arm/mach-omap2/mux.c?v=2.6.32;a=arm
So, I'm thinking that to get this working I'll need to use the newer
kernel or try and backport that functionality. Which would you
recommend? What kernel version does this patch apply to?
Hi Matt!
I worked with 2.6.32, OE version of the kernel is r78.
I don’t work with BB and may be this code, marked as +, is not required. Why don’t you just try to find out? Just experiment. I admit that driving this stupid GPIO took me a day or more until I added this strange code to init gpio.
My BSP was just cloned from arch/arm/mach-omap2/board-omap3beagle.c with adding of necessary features. My board’s schematic is based on BB, so they are almost equavalent. The only difference is in USB-host reset line and more extensive functionality like at OMAP3EVM
Max
2010/9/1 Matt Causey <matt.causey@gmail.com>