[uClinux-dev] FrameBuffer for MCF5272

Heiko Degenhardt heiko.degenhardt at sentec-elektronik.de
Tue Mar 11 06:30:31 EST 2003

Hi Dan, 

* On Wed, Mar 05, 2003 at 07:37:48AM -0800, Dan Galway, James
* Gilbrook wrote:
> We are doing a final project for a computer engineering course and
> this uClinux post is quite similar to what we are trying to
> implement.

sorry that my answer is a bit late. But theres a whole lot to do

> We are using an Epson S1D13505 LCD/CRT controller IC
> (which seems to have support for uClinux built-in).

What do you mean with "built-in"?
I know there are drivers for the S1D controllers for "normal" Linux,
but at least with that one for the 13706 we had no luck to use it
for uClinux.

> The controller will be used with an NEC NL6448AC33-13 10.4" TFT
> display.

Hm. Don't know that display. We use a Kyocera KCS057QV1AJ-G23
(1/4 VGA, 8 bit color STN).

> Currently we are designing boards.. and Heiko, if you had the
> time, it would be informative to hear if there are any cautions or
> advice you'd have in working with the Epson display controller.
> We assume it is feasible to get this controller up and running
> under uClinux and Microwindows, but we could find no information
> on people  who have done this.

Ok. I'll try to remember some of the problems we had.

- Be very careful what display you use! See if your choosed display
  is made for doing such a task, where you have to plug and unplug
  the cable very often etc.!
- Allways ensure that you have the latest data sheets (and erata
  sheets) for all components, as the Coldfire, the LCD controller,
  the display etc.
- Pay attention to the used /CS. On our board we had to use a pull
  up resistor (4.7k) to get it working corrctly, but that depends on
  your specific layout (in our case the /CS is driven).
- We use the Generic#1 interface, but with some corrections
- You have to connect the config pins (in our case CNF[7:0] to suit
  your needs.
  We use:
  CNF[2:0]  = 011 Generic#1 interface
  CNF[3]    = 1   GPIO pins are inputs at PWR ON
  CNF[4]    = 1   Big Endian bus interface
  CNF[5]    = 1   /Wait is active high
  CNF[7:6]  = 01  BCLK is 1/2 CLKI
- We had some trouble getting the /WE0 and /WE1 line connected
  correctly (there was a mistake in the coldfire data sheet).
  We now use /BS1 and /BS0 as input for the logic that drives 
  /WE0 and /WE1.
- Set up the /CS as needed (in your bootloader or in your
  crt0_ram.S. We have:
   // set up CS1:
   move.l   #0x40000201, %d0
   move.l   %d0, (MCF_MBAR + MCFSIM_CSBR1)
   move.l   #0xfff000fc, %d0
   move.l   %d0, (MCF_MBAR + MCFSIM_CSOR1)
   // enable /TA at PB5:
   move.l   #0x55554555, %d0
   move.l   %d0, (MCF_MBAR + MCFSIM_PBCNT)
  (as you see we use /TA for that chip select, no waitstates).

Now some more general rules for the design of such a board:
- Ensure that the data lines are not too small, eg. 12mil minimum
- Layout the power supply lines as big as possible
- The lines to the display should be as short as possible
  (the cable that came with our display were to long, too).

The steps we followed were:
- Get the hardware layouted and everything connected
- Do some measurements if the board and the controller work as
  required (voltage levels and currents are as expected)
- Do some small software tests, for instance with m68k-bdm-elf-gdb
  or Motorolas dBUG. That means: Try to read the version register,
  try to write some registers, try to access the graphic memory etc.
  (this way you can for instance check if your address and data lines
  are connected correctly. We found a mistake in the data sheet of
  another display we used by testing that).
- Write some small test programs for the initialization of the whole
  thing, to read/write the registers, to read/write/fill the memory
- Implement the framebuffer driver. In our case that meant:
  Creation of:
  Changing of:
  (I wanted to clean up the whole thing a bit before I would send
  the patches to Greg to get it into CVS. But I'll have not enough
  time in the next month to do that. So if you are interested I
  would just send you my "pre" stuff).
- Adjust the Microwindows stuff a bit to get it compiled under
  uClinux and to use the new driver.
REMARK: I'm not shure if everything we did is correct or doesn't
destroy something! All I can tell is that it run on our board during
an exibition some weeks ago without problems!
It's allso possible that I forgot some steps that we did. Please
only use the above as some hints, not as guidelines!

If you have further questions please let me know.

More information about the uClinux-dev mailing list