uClinux PORT to S3C44B0X
S3C44B0X is a ARM7 16/32-bit RISC microprocessor is designed to provide a cost-effective and high performance
micro-controller solution for hand-held devices and general applications. To reduce total system cost, S3C44B0X
also provides the following: 8KB cache, optional internal SRAM, LCD controller, 2-channel UART with handshake, 4-
channel DMA, System manager (chip select logic, FP/ EDO/SDRAM controller), 5-channel timers with PWM, I/O
ports, RTC, 8-channel 10-bit ADC, IIC-BUS interface, IIS-BUS interface, Sync. SIO interface and PLL for clock.
Great thing here on S3C44B0X is that it has LCD Controller in built.
So it will b easy to interface with LCD, In this case we have interfaced to Panasonic L78C64 7" panel.
Feature of LCD Controller
· Supports color/monochrome/gray LCD panel
· Supports single scan and dual scan displays
· Supports virtual screen function
· System memory is used as display memory
· Dedicated DMA for fetching image data from
system memory
· Programmable screen size
· Gray level: 16 gray levels
· 256 Color levels
For More other details plz refer to User manual of the Processor.
So Know let us know what is a Frame buffer?
A framebuffer is a video output device that drives a video display from a memory buffer containing a complete frame of data. The information in the buffer typically consists of color values for every pixel (point that can be displayed) on the screen. Color values are commonly stored in 1-bit monochrome, 4-bit palettized, 8-bit palettized, 16-bit highcolor and 24-bit truecolor formats.
A framebuffer device is an abstraction for the graphic hardware. It represents the frame buffer of some video hardware, and allows application software to access the graphic hardware through a well-defined interface, so that the software doesn't need to know anything about the low-level interface stuff.
Seriously, the major advantage of the framebuffer drives is that it presents a generic interface across all platforms. It was the case until late in the 2.1.x kernel development process that the Intel platform had console drivers completely different from the other console drivers for other platforms. With the introduction of 2.1.109 all this has changed for the better, and introduced more uniform handling of the console under the Intel platforms and also introduced true bitmapped graphical consoles bearing the Penguin logo on Intel for the first time, and allowed code to be shared across different platforms. Note that 2.0.x kernels do not support framebuffer devices, but it is possible someday someone will backport the code from the 2.1.x kernels to 2.0.x kernels. There is an exception to that rule in that the v0.9.x kernel port for m68k platforms does have the framebuffer device support included.
With the release of the 2.2.x kernel, framebuffer device support is very solid and stable. You should use the framebuffer device if your graphic card supports it, if you are using 2.2.x kernels. Older 2.0.x kernels does not support framebuffer devices, at least on the Intel platform.
Writing Linux LCD drivers
Writing Linux LCD drivers
Abstract
1 LCD Module\Driver\Controller
2 Linux Frame Buffer Driver
2.1 Why Frame Buffer?
2.2 What is Frame Buffer Devices?
2.3 How to Write Frame Buffer Device Drivers?
3 Analysis of Linux Frame Buffer Driver Source Codes
3.1 fb.h
3.2 fbmem.c
4 Skeleton of LCD controller rivers
4.1 Allocate a system memory as video memory
4.2 Implement the fb_ops functions
2 Linux Frame Buffer Driver
2.1 Why Frame Buffer?
If GUIs (Graphic User Interface) such as MiniGUI, MicroWindows are used, LCD device drivers must be implemented as Linux frame buffer device drivers in addition to those low level operations which only deal with commands provided by LCD controllers.
2.2 What is Frame Buffer Devices?
The frame buffer device provides an abstraction for the graphics hardware. It represents the frame buffer of some video hardware and allows application software to access the graphics hardware through a well-defined interface, so the software doesn't need to know anything about the low-level (hardware register) stuff.
The device is accessed through special device nodes, usually located in the /dev directory, ie /dev/fb*.
More description about frame buffer device can be found in two txt files: linux / Documentation / fb / framebuffer.txt and linux / Documentation / fb / interal.txt
2.3 How to Write Frame Buffer Device Drivers?
There are few instructive materials about writing frame buffer device drivers. You may find “Linux Frame buffer Driver Writing HOWTO” at this web page http: /linux-fbdev.sourceforge.net /HOWTO /index.html, but the HOWTO is somewhat curt and not enough. So having a look into Linux source codes is necessary. The next section is an analysis of the related source codes.
3 Analysis of Linux Frame Buffer Driver Source Codes
Linux implements Frame Buffer Drivers mainly based on the groundwork of these two files:
1) linux/include/linux/fb.h
2) linux/drivers/video/fbmem.c
It's time to have a close look at them.
3.1 fb.h
Almost all important structures are defined in this file. First let me describe what each means and how they are used one by one..
1) fb_var_screeninfo
It is used to describe the features of a video card you normally can set. With fb_var_screeninfo, you can define such things as depth and the resolution you want.
struct fb_var_screeninfo {
__u32 xres; /* visible resolution */
__u32 yres;
__u32 xres_virtual; /* virtual resolution */
__u32 yres_virtual;
__u32 xoffset; /* offset from virtual to visible */
__u32 yoffset; /* resolution */
__u32 bits_per_pixel; /* guess what */
__u32 grayscale; /* != 0 Graylevels instead of colors */
struct fb_bitfield red; /* bitfield in fb mem if true color, */
struct fb_bitfield green; /* else only length is significant */
struct fb_bitfield blue;
struct fb_bitfield transp; /* transparency */
__u32 nonstd; /* != 0 Non standard pixel format */
__u32 activate; /* see FB_ACTIVATE_* */
__u32 height; /* height of picture in mm */
__u32 width; /* width of picture in mm */
__u32 accel_flags; /* acceleration flags (hints) */
/* Timing: All values in pixclocks, except pixclock (of course) */
__u32 pixclock; /* pixel clock in ps (pico seconds) */
__u32 left_margin; /* time from sync to picture */
__u32 right_margin; /* time from picture to sync */
__u32 upper_margin; /* time from sync to picture */
__u32 lower_margin;
__u32 hsync_len; /* length of horizontal sync */
__u32 vsync_len; /* length of vertical sync */
__u32 sync; /* see FB_SYNC_* */
__u32 vmode; /* see FB_VMODE_* */
__u32 reserved[6]; /* Reserved for future compatibility */
};
2) fb_fix_screeninfon
It defines the properties of a card that are created when you set a mode and can't be changed otherwise. A good example is the start address of the framebuffer memory. This can depend on what mode is set. Now while using that mode, you don't want to have the memory position change on you. In this case, the video hardware tells you the memory location and you have no say about it.
struct fb_fix_screeninfo {
char id[16]; /* identification string eg "TT Builtin" */
unsigned long smem_start; /* Start of frame buffer mem */
/* (physical address) */
__u32 smem_len; /* Length of frame buffer mem */
__u32 type; /* see FB_TYPE_* */
__u32 type_aux; /* Interleave for interleaved Planes */
__u32 visual; /* see FB_VISUAL_* */
__u16 xpanstep; /* zero if no hardware panning */
__u16 ypanstep; /* zero if no hardware panning */
__u16 ywrapstep; /* zero if no hardware ywrap */
__u32 line_length; /* length of a line in bytes */
unsigned long mmio_start; /* Start of Memory Mapped I/O */
/* (physical address) */
__u32 mmio_len; /* Length of Memory Mapped I/O */
__u32 accel; /* Type of acceleration available */
__u16 reserved[3]; /* Reserved for future compatibility */
};
3) fb_cmap
Device independent colormap information. You can get and set the colormap using the FBIOGETCMAP and FBIOPUTCMAP ioctls.
struct fb_cmap {
__u32 start; /* First entry */
__u32 len; /* Number of entries */
__u16 *red; /* Red values */
__u16 *green;
__u16 *blue;
__u16 *transp; /* transparency, can be NULL */
};
4) fb_info
It defines the current state of the video card. fb_info is only visible from the kernel. Inside of fb_info, there exist a fb_ops which is a collection of needed functions to make driver work.
struct fb_info {
char modename[40]; /* default video mode */
kdev_t node;
int flags;
int open; /* Has this been open already ? */
#define FBINFO_FLAG_MODULE 1 /* Low-level driver is a module */
struct fb_var_screeninfo var; /* Current var */
struct fb_fix_screeninfo fix; /* Current fix */
struct fb_monspecs monspecs; /* Current Monitor specs */
struct fb_cmap cmap; /* Current cmap */
struct fb_ops *fbops;
char *screen_base; /* Virtual address */
struct display *disp; /* initial display variable */
struct vc_data *display_fg; /* Console visible on this display */
char fontname[40]; /* default font name */
devfs_handle_t devfs_handle; /* Devfs handle for new name */
devfs_handle_t devfs_lhandle; /* Devfs handle for compat. symlink */
int (*changevar)(int); /* tell console var has changed */
int (*switch_con)(int, struct fb_info*);
/* tell fb to switch consoles */
int (*updatevar)(int, struct fb_info*);
/* tell fb to update the vars */
void (*blank)(int, struct fb_info*); /* tell fb to (un)blank the screen */
/* arg = 0: unblank */
/* arg > 0: VESA level (arg-1) */
void *pseudo_palette; /* Fake palette of 16 colors and
the cursor's color for non
palette mode */
/* From here on everything is device dependent */
void *par;
};
5) struct fb_ops
User application program can use ioctl() system call to operate low LCD hardware. Methods defined in fb_ops structure are used to support these operations.
struct fb_ops {
/* open/release and usage marking */
struct module *owner;
int (*fb_open)(struct fb_info *info, int user);
int (*fb_release)(struct fb_info *info, int user);
/* get non settable parameters */
int (*fb_get_fix)(struct fb_fix_screeninfo *fix, int con,
struct fb_info *info);
/* get settable parameters */
int (*fb_get_var)(struct fb_var_screeninfo *var, int con,
struct fb_info *info);
/* set settable parameters */
int (*fb_set_var)(struct fb_var_screeninfo *var, int con,
struct fb_info *info);
/* get colormap */
int (*fb_get_cmap)(struct fb_cmap *cmap, int kspc, int con,
struct fb_info *info);
/* set colormap */
int (*fb_set_cmap)(struct fb_cmap *cmap, int kspc, int con,
struct fb_info *info);
/* pan display (optional) */
int (*fb_pan_display)(struct fb_var_screeninfo *var, int con,
struct fb_info *info);
/* perform fb specific ioctl (optional) */
int (*fb_ioctl)(struct inode *inode, struct file *file, unsigned int cmd,
unsigned long arg, int con, struct fb_info *info);
/* perform fb specific mmap */
int (*fb_mmap)(struct fb_info *info, struct file *file, struct vm_area_struct *vma);
/* switch to/from raster image mode */
int (*fb_rasterimg)(struct fb_info *info, int start);
};
6) structure map
struct fb_info_gen | struct fb_info | fb_var_screeninfo
| | fb_fix_screeninfo
| | fb_cmap
| | modename[40]
| | fb_ops ---|--->ops on var
| | ... | fb_open
| | | fb_release
| | | fb_ioctl
| | | fb_mmap
| struct fbgen_hwswitch -|-> detect
| | encode_fix
| | encode_var
| | decode_fix
| | decode_var
| | get_var
| | set_var
| | getcolreg
| | setcolreg
| | pan_display
| | blank
| | set_disp
/*DOTCLK = fframe × (X + HBP + HFP+HSPW) × (Y + VBP + VFP+VSPW)(unit：MHz)*/
/*pixclock = 10 to 12 th / DOTCLK (unit: pico seconds)fframe frame table ，generally its taken as 60*/
struct fbgen_hwswitch is an abstraction of hardware operations. It is not necessary, but sometimes useful.
3.2 fbmem.c
fbmem.c is at the middle place of frame buffer driver architecture. It provides system calls to support upper user application programs. It also provides an interface to low level drivers for specific hardware. Those low level frame buffer drivers can register themselves into the kernel by this interface. fbmem.c implements the common codes used by all drivers, thus avoids repeated work.
1) Global Varibles
struct fb_info *registered_fb[FB_MAX];
int num_registered_fb;
The two are used to record on-using instance of fb_info structure. fb_info represents the current state of video card. All fb_info structures are globally placed in an array. When a frame buffer registers itself to kernel, a new fb_info is added to this array and num_registered_fb increases 1.
static struct {
const char *name;
int (*init)(void);
int (*setup)(void);
} fb_drivers[] __initdata= { ....};
If frame buffer driver is static linked into kernel, a new entry must be added to this table. If use insmod/rmmod, don’t care this.
static struct file_operations fb_ops ={
owner: THIS_MODULE,
read: fb_read,
write: fb_write,
ioctl: fb_ioctl,
mmap: fb_mmap,
open: fb_open,
release: fb_release
};
This is the interface to user application programs. fbmem.c implements these functions here.
2) register_framebuffer(struct fb_info *fb_info)
unregister_framebuffer(struct fb_info *fb_info)
This is the interface to low level frame buffer device driver. The drivers use this pair of functions to register or unregister themselves.
Almost all the work those low level drivers needed to do is to fill in an fb_info structure and then to (un)register it.
4 Skeleton of LCD controller rivers
LCD drivers operate LCD device hardwares, while fbmem.c records and administrates these drivers. There is a skeleton frame buffer driver in linux /drivers /fb /skeleton.c. It shows how to implement a frame buffer driver with very few codes. Because it is too simple, it does nothing but filling an fb_info and then (un)registering it.
In order to implement a usable LCD controller driver, something else must be added into it. But what should be added? As we all know, device drivers abstract hardware and provide system call interface to user programs. So we can implements the low level hardware operations according to the need of the system call interface, namely the file_operations structure which is discussed in section 3.2.
4.1 Allocate a system memory as video memory
After a careful lookup in fbmem.c, we know that open() and release() method of file_operations structure do not need low level support, while read(), write() and mmap() need a common support function fb_get_fix(). So fb_get_fix() must be provided by driver writers.
Additionally the writer should allocate a system memory as video memory, for most LCD controllers have no their own video memory. The allocated memory start address and length are later placed in smem_start and smem_len fields of fb_fix_screeninfo structure. The allocated memory should be physically consecutive.
4.2 Implement the fb_ops functions
The only method of file_operations still not discussed is ioctl(). User application programs use ioctl() system call to operate LCD hardware. Methods defined in fb_ops structure(section 3.1) are used to support these operations. NOTE: fb_ops structure is NOT file_operations structure. fb_ops is for abstraction of low level operations, while file_operations is for upper level system call interface
Again we’d better first decide which methods should be implemented. ioctl() system call is implemented in fbmem.c, so we turn to it and quickly we can find out such relationship between ioctl() commands and fb_ops’s methods:
FBIOGET_VSCREENINFO fb_get_var
FBIOPUT_VSCREENINFO fb_set_var
FBIOGET_FSCREENINFO fb_get_fix
FBIOPUTCMAP fb_set_cmap
FBIOGETCMAP fb_get_cmap
FBIOPAN_DISPLAY fb_pan_display
Now we know that if we implement these fb_XXX_XXX functions, then user application writers can use FBIOXXXX micros to operate LCD hardwares. But how can we implement them?
It is fine to have a reference to linux/drivers/video/fbgen.c or other drivers under the linux/drivers/video directory.
Among these functions, fb_set_var() is the most important. It is used to set video mode and more. The following is the common steps performed by a fb_set_var() function:
1) Check if mode setting is necessary
2) Set the mode
3) Set colormap
4) Reconfigure the registers of LCD controller according former settings
The fourth step shows where low level operations are placed. Curious men may have such a question: how image data of user application are put onto the screen. Driver writer allocates a system memory as video memory, and later he sets the start address and length of the memory to LCD controller’s registers(often in fb_set_var() function). The content of the memory will be sent to screen automatically by LCD controller(for details, see specific LCD controller). On the other hand, the allocated system memory is mapped to user space by mmap(). Thereby, when a user sends data to the mapped memory, the data will be shown on LCD screen.
Reference
1 and 2 For LCD Technology data sheet.
3 linux/Documentation/fb/framebuffer.txt
4 linux/Documentation/fb/interal.txt
5 Linux Framebuffer Driver Writing HOWTO
http:/linux-fbdev.sourceforge.net/HOWTO /index.html
6 linux/include/linux/fb.h
7 linux/drivers/video/fbmem.c
8 linux/drivers/video/skeletonfb.c
9 linux/drivers/video/fbgen.c
10 linux/drivers/video/tgafb.c
Now Some practical Things : kernel Setting options and Compiling the Kernel for Customized Use, Ok.
1 Open the FrameBuffer support uClinux
1.1
modify / uClinux-dist/vendors/Samsung/44B0/config.linux-2.4.x
Determine
CONFIG_VT = y / / VT is Virtual Terminal
1.2
Modifications / uClinux-dist/linux-2.4.x/drivers/video/s3c44b0xfb.c
By default is to support 16 gray screen, if it is 256 color screen, you'll need to
comment out # define LCD_GRAY_16.
Fb0 equipment increased 1.3
Modify vendors/Samsung/44B0/Makefile
1.4 driver identified
linux-2.4.x/drivers/video/Config.in
if [ "$ CONFIG_CPU_S3C44B0X" = "y"]; then
tristate 'Samsung S3C44B0X built-in LCD controller frame buffer support' CONFIG_FB_S3C44B0X
fi
linux-2.4.x/drivers/video/Makefile
obj-$ (CONFIG_FB_S3C44B0X) + = s3c44b0xfb.o
linux-2.4.x/drivers/video/fbmem.c
extern int s3c44b0xfb_init (void);
extern int s3c44b0xfb_setup (void);
# ifdef CONFIG_FB_S3C44B0X
( "S3c44b0xfb", s3c440xfb_init, s3c44b0xfb_setup),
# endif
In Make file of Vendors:i..e.,
/ uClinux-dist/vendors/Samsung/44B0/Makefile
DEVICES = \
fb0, c, 29,0
1.5
Compiling uClinux
FrameBuffer part of the configuration options
/************************************************* *******************************
*
*
Console drivers
*
VGA text console (CONFIG_VGA_CONSOLE) [N / y /?] (NEW) n
Support Frame buffer devices (CONFIG_FB) [N / y /?] (NEW) y
*
*
Frame-buffer support
*
Support for frame buffer devices (EXPERIMENTAL) (CONFIG_FB) [Y / n /?]
Acorn VIDC support (CONFIG_FB_ACORN) [N / y /?] (NEW) n
CLPS711X LCD support (CONFIG_FB_CLPS711X) [N / y /?] (NEW) n
Cyber2000 support (CONFIG_FB_CYBER2000) [N / y /?] (NEW) n
SA-1100 LCD support (CONFIG_FB_SA1100) [N / y /?] (NEW) n
Advanced low level driver options (CONFIG_FBCON_ADVANCED) [N / y /?] (NEW) y
Monochrome support (CONFIG_FBCON_MFB) [N / y /?] (NEW) n
2 bpp packed pixels support (CONFIG_FBCON_CFB2) [N / y /?] (NEW) n
4 bpp packed pixels support (CONFIG_FBCON_CFB4) [N / y /?] (NEW) n
16 bpp packed pixels support (CONFIG_FBCON_CFB16) [N / y /?] (NEW) n
24 bpp packed pixels support (CONFIG_FBCON_CFB24) [N / y /?] (NEW) n
32 bpp packed pixels support (CONFIG_FBCON_CFB32) [N / y /?] (NEW) n
Amiga bitplanes support (CONFIG_FBCON_AFB) [N / y /?] (NEW) n
Amiga interleaved bitplanes support (CONFIG_FBCON_ILBM) [N / y /?] (NEW) n
Atari interleaved bitplanes (2 planes) support (CONFIG_FBCON_IPLAN2P2) [N / y /?] (NEW) n
Atari interleaved bitplanes (4 planes) support (CONFIG_FBCON_IPLAN2P4) [N / y /?] (NEW) n
Atari interleaved bitplanes (8 planes) support (CONFIG_FBCON_IPLAN2P8) [N / y /?] (NEW) n
Amiga bitplanes support (CONFIG_FBCON_AFB) [N / y /?] (NEW) n
Amiga interleaved bitplanes support (CONFIG_FBCON_ILBM) [N / y /?] (NEW) n
Atari interleaved bitplanes (2 planes) support (CONFIG_FBCON_IPLAN2P2) [N / y /?] (NEW) n
Atari interleaved bitplanes (4 planes) support (CONFIG_FBCON_IPLAN2P4) [N / y /?] (NEW) n
Atari interleaved bitplanes (8 planes) support (CONFIG_FBCON_IPLAN2P8) [N / y /?] (NEW) n
Mac variable bpp packed pixels support (CONFIG_FBCON_MAC) [N / y /?] (NEW) n
VGA 16-color planar support (CONFIG_FBCON_VGA_PLANES) [N / y /?] (NEW) n
VGA characters / attributes support (CONFIG_FBCON_VGA) [N / y /?] (NEW) n
HGA monochrome support (EXPERIMENTAL) (CONFIG_FBCON_HGA) [N / y /?] (NEW) n
Support only 8 pixels wide fonts (CONFIG_FBCON_FONTWIDTH8_ONLY) [N / y /?] (NEW) n
Select compiled-in fonts (CONFIG_FBCON_FONTS) [N / y /?] (NEW) y
VGA 8x16 font (CONFIG_FONT_8x16) [N / y /?] (NEW) y
Sparc console 8x16 font (CONFIG_FONT_SUN8x16) [N / y /?] (NEW) n
Pearl (old m68k) console 8x8 font (CONFIG_FONT_PEARL_8x8) [N / y /?] (NEW) n
Acorn console 8x8 font (CONFIG_FONT_ACORN_8x8) [N / y /?] (NEW) n
Virtual terminal (CONFIG_VT) [Y / n /?]
Support for console on virtual terminal (CONFIG_VT_CONSOLE) [N / y /?] (NEW) n
************************************************** *******************************/
Because it is 256 color LCD, so I chose the following
After downloading the kernel if access to the system, the Virtual Terminal will not run, if the account can not be used after fb0 will have to be elected, because they do not, then the election will be shielded
Support Frame buffer devices (CONFIG_FB) [N / y /?] (NEW) y
settings, Virtual Terminal is the meaning of the data shown in HyperTerminal in LCD display, at the same time also shows HyperTerminal.
