Beaglebone + LIDD-capable LCD

[KermM]

I've been playing around with my BeagleBone for a few weeks now, and I figured it was time to try to connect an LCD to it. After a fair bit of digging, kernel-compile, and testing, I've decided that I might as well run my questions by the experts to see if you guys can shed some light. First of all, what I know and what I've tried:

- I have a 320x240 RGB LCD (with SPI touchscreen) that has either an HX8347-A or SSD1289 compatible display driver.
- The AM335x has an LCDC that supports Raster and LIDD modes. Based on the pinout of the display (D0-D15, CS, RS [aka CD], WR, RD, RESET), I believe it requires LIDD mode
- From the 5000-page AM335x manual, I found the proper pin mappings and got my display all hooked up.
- I looked for and found a /drivers/video/ssd1289 module for another platform that I could theoretically port
- I found via http://processors.wiki.ti.com/index.php/AM335x_LCD_Controller_Driver%27s_Guide that I should look at the da8xx module for the am335x as a start
- I downloaded and built the Angstrom source kernel and root image via Angstrom's git repository. I also tried the Angstrom Narcissus tool, but had less success
- I managed to build Angstrom successfully, and I managed to perform a menuconfig that confirmed that the da8xx driver was configured. I tried as built-in and as a module
- In neither case, performing a console-image build, could I manage to actually get anything related to the da8xx to appear in the kernel or as a module. Perhaps I need a GUIfied image?
- Unfortunately, trying to build a full GUI image with gnome and friends failed due to bad XML in one of the gdm components
- I searched through the many files in the Angstrom bitbake directories, and found such interesting items as patches for the Beagleboard Toys' ULCD7 (which appears to use the Raster mode, not the LIDD mode)
- I tried copying over the kernel source directory from my cross-compiling Linux machine to my Beaglebone itself, but ran into myriad problems trying to build the da8xx module manually on the 'bone.

At this point, I believe that my plan of attack should be something like this:
- Get the da8xx driver to somehow build, anywhere
- Insmod it and see if I can use it to get anything to appear on my LCD
- If not, merge the SSD1289 module I found for another platform as a patch / extension to the da8xx driver
- If and when I get it working as a driver, figure out how to compile it directly into the kernel.

Thanks in advance for any feedback, experience, or comments you might have; please don't hesitate to ask any additional questions you might have about what steps and approaches I have or have not yet tried.

[Rod Holum]

I too have tried to do the same thing, but with a 20x4 LCD screen, to no avail, if anyone could shed some light on how to do this properly please let me know. Thanks

[Thomas Fogh Damgaard]

I have the same problems, so I'm hooking on this thread. :)

I'm using a 320x240 LCD that has a HX8238-A compatible display driver and a Focaltech FT5206 touch driver.

[Thomas Fogh Damgaard]

I have a 320x240 LCD with a HX8238A display driver and a FocalTech FT5206 touch driver.

When I try to read from/write to the LCD controller CTRL reg (address 4830E004) I get a segmentation fault. If I try the same with the USBSS REVREG (address 47400000) I don't.

Den tirsdag den 1. maj 2012 02.34.50 UTC+2 skrev KermM:

[fanfan]

Interesting topic. Does anyone look at this LCD: 4.3" PSP Sharp Screen http://www.sparkfun.com/products/8335. 

I don't think this LCD has display driver chip. It can connect ARM pin directly. Is it correct?

[KermM]

Thomas: Are you working from kernel space or user space? From user space, virtual memory remapping will prevent that from working properly.

FanFan: I believe that LCD may require the Raster mode of the AM335x instead of the LIDD mode, from reading the datasheet for the LCD. I also believe that the existing da8xx drivers might actually already support that LCD.

As far as my own issue, I have confirmed that my LCD has an SSD1289 driver, but I haven't had a chance to continue trying to get kernel modules compiled on my Beaglebone or figure out why the module isn't appearing in my console-image bitbake builds. Thanks in advance to anyone with thoughts!

[Hiremath, Vaibhav]

On Wed, May 02, 2012 at 18:41:33, Thomas Fogh Damgaard wrote:
> I have a 320x240 LCD with a HX8238A display driver and a FocalTech
> FT5206 touch driver.
> When I try to read from/write to the LCD controller CTRL reg (address
> 4830E004) I get a segmentation fault. If I try the same with the USBSS
> REVREG (address 47400000) I don't.
>

Most likely the reason could be, the clock is not enabled for the module.
Can you check whether fb driver is registered properly to the kernel? If
could possible that, registration has failed and clock has been disabled
during boot.

Just FYI, assuming that, the module is enabled, you should be able to read
the registers from user space via devmem tool.

Thanks,
Vaibhav

[Hiremath, Vaibhav]

On Wed, May 02, 2012 at 19:38:13, fanfan wrote:
> Interesting topic. Does anyone look at this LCD: 4.3" PSP Sharp Screen
> http://www.sparkfun.com/products/8335.
>

Can you try "LK043T1DG01", looks from same family? It is already supported
by driver.

Reference platform hookup can be found at
arch/arm/mach-davinci/board-da850-evm.c
arch/arm/mach-davinci/devices-da8xx.c

Thanks,
Vaibhav

[Thomas Fogh Damgaard]

The clock wasn't enabled... Just a noob question: Does the clock start if I load the fb module manually (insmod)? Thanks!

[Koen Kooi]

Op 3 mei 2012, om 08:35 heeft Thomas Fogh Damgaard het volgende geschreven:

> The clock wasn't enabled... Just a noob question: Does the clock start if I load the fb module manually (insmod)? Thanks!

You have to edit the da8xx driver and the boardfile to add your display and recompile those. The angstrom kernel that comes with the boards has a number of examples on how to do that (dvi cape, vga cape, 7" lcd cape, 3.5" lcd cape, etc).

[Thomas Fogh Damgaard]

I'm looking into the da8xx driver. Boardfile?

Where can I find the examples?

Thanks!

[Christopher Mitchell]

How can you make it use the driver even if the cape isn't present, as indicated an an EEPROM?
Thanks.

-- To join: http://beagleboard.org/discuss
To unsubscribe from this group, send email to:
beagleboard...@googlegroups.com
Frequently asked questions: http://beagleboard.org/faq

[Hiremath, Vaibhav]

On Thu, May 03, 2012 at 21:23:13, Christopher Mitchell wrote:
> How can you make it use the driver even if the cape isn't present, as
> indicated an an EEPROM?
> Thanks.
>

You can tweak the kernel code (which I wouldn't recommend) to always
initialize the lcdc port, by adding following line,

{lcdc_init, DEV_ON_DGHTR_BRD, PROFILE_NONE},

Into the "beaglebone_dev_cfg" config list, present in file
arch/arm/mach-omap2/board-am335x.evm.c

Thanks,
Vaibhav

[KermM]

I wanted to mention that since I posted this thread, I've been teaching myself what I need to know, and have succeeded in setting up a kernel development environment, building custom kernels, figuring out the obscure places Bitbake likes to put files, figured out how to create Bitbake patches and patch the board_am335xevm.c file for new drivers with initialization routines and I/O pin requirements, and started building an SSD1289 driver for the AM335x based on the existing SSD1289 driver for another platform. I have successful driver probing and initialization working, and can request and remap the necessary resources, successfully read the AM335x's LCDC PID from its MMIO registers, and (apparently) write to the CSO_DATA/ADDR registers. However, I discovered that the driver kernel panics with error 0x1028 when I try to read LIDD_CS0_ADDR. From my debugging experience thus far, 0x1028 indicates either an unaligned read/write or that power or clock for the module has not been properly enabled. I know that I'm enabling the power, since I'm able to read the LCDC PID without a kernel panic (and get a valid value), but I'm assuming there's some other clock or setting I'm accidentally omitting. I've also not worried too much about getting the read/write prolog/strobe/epilog timings right so far, as I doubt that could cause this abort, but I'll worry about that once I get the abort solved.

[Thomas Fogh Damgaard]

Great work! :) I'm still stuck. :(

I've changed the mux to lcd config. (Just added a init script.)

I can't find a board file in the kernel the Ångström setup script compiled. (Found arch/arm/mach-omap2/board-omap3beagle.c in a kernel I downloaded from kernel.org)

I'm pretty sure I can modify the da8xx-fb.c driver, but I don't know how to integrate it (insmod'ing doesn't start it - I guess I need the device part, but don't know what to do).
Any help would be much appreciated!

[Hiremath, Vaibhav]

On Wed, May 09, 2012 at 13:13:38, Thomas Fogh Damgaard wrote:
> Great work! :) I'm still stuck. :(
> I've changed the mux to lcd config. (Just added a init script.)
> I can't find a board file in the kernel the Ångström setup script
> compiled. (Found arch/arm/mach-omap2/board-omap3beagle.c in a kernel I
> downloaded from kernel.org)

You are referring to wrong file, you should refer to the board-am335xevm.c
File, which is used for BeagleBone.

Thanks,
Vaibhav

[KermM]

Still no luck with deferred I/O, but I was able to finally get everything to work together. Screenshots of Tux, a tiny htop, and an Angstrom login prompt (over on the second page): http://www.cemetech.net/forum/viewtopic.php?p=183376#183376 . It's quite slow without deferred I/O and without DMA, though, so I'm currently overhauling it to use the AM335x's LCDC's DMA features and its interrupt mechanism.

[Christopher Mitchell]

I just wanted to let you guys know that I successfully completed my DMA LIDD driver for SSD1289-based displays. I wrote up a detailed article about all the things I've discovered about the LCDC, the LIDD module of which seems to be almost entirely undocumented publicly. I've also published the current version of my patch, which is stable and functional (though doesn't yet let X be launched or rotate to landscape); I ask that you use proper discretion and provide due attribution if you do use or extend my patch. You can read the article and grab the patch at http://www.cemetech.net/forum/viewtopic.php?t=7814 .

On Sat, May 12, 2012 at 12:27 PM, KermM <kermm...@gmail.com> wrote:

Still no luck with deferred I/O, but I was able to finally get everything to work together. Screenshots of Tux, a tiny htop, and an Angstrom login prompt (over on the second page): http://www.cemetech.net/forum/viewtopic.php?p=183376#183376 . It's quite slow without deferred I/O and without DMA, though, so I'm currently overhauling it to use the AM335x's LCDC's DMA features and its interrupt mechanism.

[Kunpeng Fan]

I completely followed your guide but failed. What I got is just a blank LCD with white backlight.

And I used 16 (lcd data) + 4(rs, cs, rd, wr) + 4(vcc, gnd) wires to connect them.

RS <--> Vsync, pclk <--> rd, hsync <--> wr, cs <--> ac-enb-cs

Below is log. was anything wrong?

root@beaglebone:~# dmesg |grep ssd1289

[    0.162760] ssd1289_init

[    0.269965]  ssd1289.0: alias fck already exists

[    0.270130] ssd1289_probe

[    0.272879] ssd1289_probe: Raw lcd_regs=4830e000

[    0.277705] ssd1289_probe: Remapped lcd_regs=fa30e000

[    0.283063] ssd1289_probe: controller signature=0x4f201000

[    0.288812] ssd1289_probe: Initialized LCDC controller

[    0.294180] ssd1289_probe: driver signature=0x0000

[    0.299201] ssd1289 ssd1289.0: ssd1289_probe: unknown driver signature 0x0000 (reg_get failure?)

[    0.303967] ssd1289_video_alloc: item=0xcf9bfac0

[    0.308806] ssd1289_video_alloc: item=0xcf9bfac0 frame_size=153600

[    0.315265] ssd1289_video_alloc: item=0xcf9bfac0 pages_count=38 per each of 1 buffer(s)

[    0.324174] ssd1289_video_alloc: DMA set from 0x8fa00000 to 0x8fa257ff, 155648 bytes

[    0.339660] ssd1289_setup: item=0xcf9bfac0

beagleboard+unsubscribe@googlegroups.com

[Christopher Mitchell]

The log looks fine to me. I also have an updated patch for the newest Angstrom build, by the way. Are you sure about your wiring, including the odd mixup around LCD11-LCD15 where the pattern for the previous pins in the Beagle's header breaks down?

Christopher

beagleboard...@googlegroups.com

[Kunpeng Fan]

Thanks for your reply Christopher. Yes LCD11-15 is especial but after I changed pin map and made a double check, result was same.

For the log, "unknown driver signature" is not fatal error message? I uncommented first line of ssd1289.c and got these debug information.

And Another suspect point is: my LCD has pin NC and BLCNT but all are left unwired.

For patch, I think I used an old version since I have to move function to other position manually to make compile pass. But I didn't change one line logic of code.

[Christopher Mitchell]

Kunpeng,

I have uploaded a new version of the patch to Cemetech; it's now 0041... rather than 0031... Please let me know if that does the trick for you. You can also post in the Cemetech thread for the patch if that's easier. :) No, unknown driver signature is not a fatal message, it just means the LIDD was unable to execute a read from the LCD. My LCD does the same thing, hence why it isn't marked as a fatal event. NC is "not connected" and should be left unwired; BLCNT can just get hooked to 3.3v (VCC).

Cheers,
Christopher

[Kunpeng Fan]

Now the LCD can work, although not stable. LCD is always white backlight, then after 2 or 3 minutes, I reset the board. Then if I was lucky enough, the LCD got black and display text.

[Christopher Mitchell]

Kunpeng,

Sorry to hear of your difficulties; I'm afraid I can't replicate those issues. Have you made any progress stabilizing the LCD?

Christopher

[Kunpeng Fan]

It is weird since it can work sometimes. And I have gave up to try since I have no idea on it. I attached the code, which was downloaded from LCD dealer and it is for SMT32. I saw there are many difference with your ssd1289.c driver. You can give a quick look and find out something. 

Now I am building a compact wire connecting LCD and board.

Thanks,

Fan

[Christopher Mitchell]

Fan,

That code seems to make allowances for many different types of controllers that follow the same general protocol as the SSD1289, but in the end it is not THAT different, I think. One thing you might consider is to make sure your wires are short enough and that you avoid crosstalk. I discovered that with a long cable I get a noisy/corrupted display due to crosstalk.

Christopher

[engka...@gmail.com]

Hi everyone!

I want to connect an LCD for primary display to my beaglebone black. I have not yet purchased an LCD because I am still on the process of choosing which LCD works. I don't have a background on writing drivers and patching, but I can program and have experienced compiling a linux kernel for an amd geode singleboard computer in the past. 

After searching the net about LCDs and beaglebone, I learned about the builtin LCD support of the AM335x processor. So now I looked for LCDs with similar interface and I came across this: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCwQFjAA&url=http%3A%2F%2Fwww.fannal.com%2Fsupport%2Fdocument-download%2Fitem%2Fdownload%2F13_f59fd9529e0ce870e8347832c9f4822a.html&ei=7DAzUvb0FYe4iAfF7IGQBw&usg=AFQjCNHINBIAaYblpZ1cBXIqXU0qyKT6ZQ&sig2=s5nJqjlkH14jVrCn-oalqw&bvm=bv.52164340,d.aGc&cad=rja

It has 24-bit TTL interface. So my questions are:
1. Is the 24-bit TTL RGB interface stadard? That is, I can just connect this to the beaglebone with at most editing the pinmux
2. How do I know if an LCD is compatible with the AM335x processor?
3. According to the supplier the touch controller is SSD2532. What are the things do I need to do, to make the touch interface work? Do I have to make my own driver to interpret touch data from the I2C communication?

I am looking forward for your responses. 

Thank you very much.

Sincerely,
kit

[Gerald Coley]

The 24 bit is standard on all 24 bit displays. There are also 8 bit displays as well. And 16 bit displays. The BBB is setup for  16 bit displays, but you can still use the 24b display.  

As to whether it will work, a lot of displays can work. You nee dto get help form some one that knows the AM3359 processor.

There are several references for LCD that can be found by looking at the schematics for the LCDs that are already on the market, built, and ready to go.

http://circuitco.com/support/index.php?title=BeagleBone_Capes has a few isted and there others out there as well.

Gerald

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[engka...@gmail.com]

Thank you Gerald. I'm reading about device tree because I'm using the 3.8 version of the linux kernel. I'm going to make my LCD as my main display. It has capacitive touch panel. The touch has an I2C interface and uses FT5x02 driver( I have the C source for this). I think I can understand how to make a dts base on the existing dts in the kernel source. However, I am still on the process of learning it. 

[Gerald Coley]

Which BeagleBone do you have?

Gerald

[engka...@gmail.com]

Beaglebone black. Right now, I am building the circuit to power and connect my LCD, backlight and touch interface. My LCD has 24 pins for the data. I think I'll just connect 16 for now and try to modify a dts of an existing lcd cape. About the touch interface, how do I let the kernel load my driver?

[Gerald Coley]

Ever here of Device tree? You have to disable the onboard HDMI framer to use the pins for your LCD.

http://circuitco.com/support/index.php?title=BeagleBone_Black_FAQ

Gerald

[engka...@gmail.com]

Yeah. I think I can disable the onboard HDMI framer and enable my own LCD display through the cape manager at runtime or set it in the Env.txt to do it at boot process( as I have read from here http://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/exporting-and-unexporting-an-overlay). 

Here's what I have done so far. based here http://www.cemetech.net/forum/viewtopic.php?t=7814&postdays=0&postorder=asc&start=0
1. cloned the angstrom setup script
2. checkout the 2013.06 source
3. setup using the oebb.sh for beaglebone
4. compile the menuconfig and looked through it.
5. bitbake  virtual/kernel compile 

now I can see the kernel source somewhere in the build folder
Here's what I am planning to do.
1. use and edit an existing device tree  source in the firmware/capes (I'm gonna go with BB-BONE-LCD4-01-00A0.dts.
2. add the touch screen driver (I'm still figuring out where and how including how to enable the kernel to know that the driver for the touch interface in the device tree is this one.)
3. build the image.

I still can't say if I am on the right track because I have just read about device tree since yesterday.

kit

[garyamort]

On Monday, September 30, 2013 2:15:22 PM UTC-4, engka...@gmail.com wrote:

Yeah. I think I can disable the onboard HDMI framer and enable my own LCD display through the cape manager at runtime or set it in the Env.txt to do it at boot process( as I have read from here http://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/exporting-and-unexporting-an-overlay). 

It would be easiest to disable the onboard HDMI framer at boot time, and then you can test enabling and disabling the LCD display via the cape manager.

IE modify  the DTS.  Don't even worry about touchscreen for now, just focus on graphics.

Modify and compile the DTS, place the compiled mods into the /firmware directory and then send the file name to the cape manager, ie

echo yourfilename >/sys/devices/bone_capemgr.*/slots

The file is fairly self explanatory and as long as your sticking with 16 data lines your in good shape.

From the BB-BONE-LCD4-01 file you would delete the following sections:

tsadc - this is for the touchscreen, just remove it for now to avoid errors while loading it

gpio-leds-cape-lcd4 - this is for some status led's on the lcd.   While they should not cause any problems, if you remove the section then you won't have any problems

The panel section is the important one:

panel {

compatible = "tilcdc,panel";

...

This tells Linux that it should load the tilcdc panel driver and gives the configuration information.   Normally, the tilcdc driver would be loaded upon bootup and when a new device was found[either from the hdmi connection or from an i2c connection] it would auto configure based on the data.   Since your just using a raw LCD panel, you have to manually load it.  Make sure to adjust the panel-info and display-timings section to match your LCD configuration.

 One of the really cool things with the device tree  is how you should be able to configure/adjust settings for all sorts of drivers automatically.  Pre-device tree tended to require a seperately compiled "driver" for every variation.  Browsing through older video drivers, I find large numbers of C files that only exist to define panel timings for different models of LCD's.   These files are duplicated in lots of different video display drivers to add the panel definitions there.

Wheras with the device tree and TI's addition of support for fragments, you can place the timing information in one DTS fragment, and then include those fragments in the DTS file on a driver by driver basis.

[engka...@gmail.com]

Thanks. I will be focusing on the display first. I am thinking of separating the dts for the LCD display and the touch screen. Is that ok?

[garyamort]

On Tuesday, October 1, 2013 2:16:04 AM UTC-4, engka...@gmail.com wrote:

Thanks. I will be focusing on the display first. I am thinking of separating the dts for the LCD display and the touch screen. Is that ok?

The DTS just defines:

Pins to use and what mode the pin should be configured for

Possibly: some friendly labels to use to label the pins in the sysfs tree

Possibly: a driver to load and some configuration information for the driver

As such you can certainly have a separate DTS file for each function/driver[LCD, Touchscreen, Buttons, etc]

[engka...@gmail.com]

I built the backlight for my LCD using an LED driver. I tested it with LEDs and the LCD(not connected yet with BBB) and it lights up. I connected my LCD to the BBB with http://pastebin.com/8Mh8sRHB this device tree definition in slot 7. My LCD is not working. Not even the backlight. The LCD I used is http://www.lilliputuk.com/uploads/attachments/569GL_LCD.pdf.

[engka...@gmail.com]

Oh well, I got it working. I disconnected the PWM pin in the backlight controller an just left it pulled up. I now have a display. But it is a console. I though angstrom has gui. What angstrom should I flash my bbb to have the GUI? so that I can start with the touch screen now.

[garyamort]

On Saturday, October 12, 2013 6:45:21 AM UTC-4, engka...@gmail.com wrote:

Oh well, I got it working. I disconnected the PWM pin in the backlight controller an just left it pulled up. I now have a display. But it is a console. I though angstrom has gui.

When booting up, most modern linux configurations check for a working monitor when booting.  If the monitor is there it starts the windowing system.  If there is no monitor it doesn't.

Considering the window system takes a lot of memory, it just makes sense not to load it if it doesn't do anything.

If you have a keyboard connected, try logging in and running 'startx" from the command line.

If you don't have a keyboard connected, then you will need to SSH to the system...  I'm not sure what the command is from remote...maybe try 'startx &' ? 

[engka...@gmail.com]

Yey thanks. I got to see xterm. But I need to see the desktop view so that I can test the touch screen. Maybe I got the wrong image flashed to beaglebone. I used this to reflashed my BBB when SSH stop working: https://s3.amazonaws.com/angstrom/demo/beaglebone/BBB-eMMC-flasher-2013.06.20.img.xz

I think I should have flashed the one with gnome thingy.

I also had this problem that my dtbo is not loaded at boot time. I was able to unload the HDMI.
here's what's inside the uEnv.txt

optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN 

capemgr.enable_partno= name of my cape

where <name of my cape> is replaced with the name of the cape in my dts.

This does not load my LCD. So I had to load it manual into the slots.

[engka...@gmail.com]

I solve it. I edited and recompiled the am335x-bone-common.dtsi and place it in the /boot directory of the beaglebone black. it now loads the desktop and runs my LCD on startup.

[younanyounan...@gmail.com]

The device tree definition you posted no longer seems to be online.  I'm using an SSD1289, do you think you could help me?

[alexoma...@gmail.com]

Is there anyway you would still have this dts file available? the pastebin link is dead.

On Saturday, October 12, 2013 5:28:43 AM UTC-4, engka...@gmail.com wrote: