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's_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.
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
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.
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.
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?
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!
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
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
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).
I’m looking into the da8xx driver. Boardfile?
Where can I find the examples?
Thanks!
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
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.
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!
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
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.
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 .
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
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