Compile my driver module into linux image uImage for flash nand

Sounds like your driver has been developed as a loadable module that is outside the kernel source. The easiest way to get your code into kernel is to include your code in the board specific code. For example, let's say your board is OMAP2 based, change the target in arch/arm/mach-omap2/Makefile to include your driver code. Something like this:

obj-$(CONFIG_MACH_YOUR_BOARD)         += board-your-board.o your-driver.o

Copy your-driver.c into arch/arm/mach-omap2. A more "proper" way would be to create a driver directory, modifying the makefiles, the kconfig scripts, etc. to allow inclusion through menuconfig. Lot a work thats gets overwritten every time your upgrade your kernel.

You might be able to add M=path_to_your_driver on your kernel build. The makefile in your driver directory would have a target of obj-y instead of obj-m. Never tried it.

Some companies don't like to compile a custom driver module into the kernel as its makes the module GPL'ed.

The order that builtin modules load in not directly controllable. If your module is depends on another module, that module may not be loaded prior to your module. I vaguely remember built-in modules are loaded in compile order.

You can automatically load your module after boot though inittab and the init scripts.

Hi Norman,

Thanks for the quick and detai answers. The module I am trying to put into image is compiled into .ko file now and can be run in the kernel by using insmod and rmmod. Just make sure you suggest me to use .o file instead of .ko, right?

What do you mean by through inittab and init scripts? I need to run the module automatically without any script. If run script, I can run insmod and rmmod so it would be easier, right?

Also how can I compile user space application code into automatic run after boot up?

Thanks.

Fran

For built-in modules, I'd suggest copying your custom driver source (.c, .h) into the kernel tree. Usually in the same directory as your board init source file. Add the source files to the nearby makefile. If all goes well, you will see object files (.o) for your driver source. What should happen is that the kernel will automatically call the init function in your module on boot.

For loadable modules, you can load them at boot by using the init and runlevel system. The key file to look at is /etc/inittab and the /etc/init* subdirectories. The most direct method is to modify /etc/init. It's been a while, several years ago this line would work:

null::once:/root/my_run_script

And /root/my_run_script is an executable shell script that would contain something like:

insmod my_driver.ko
./my_app

The syntax of the inittab file has changed over the years. You'll have to experiment.

A more elegant complicated way to load modules at boot is to use runlevels. I don't have my dev system in front of me. ..so take this with a grain of salt. The runlevel system is what loads stuff like the the network on boot and unloads the same stuff on shutdown. The system consists of shell scripts (in /etc/init.d?) and symbolic links (in /etc/rc*.d?). The name of the symbolic links control what arguments are passed to script when called. Names starting with 'S' are for entering a runlevel and 'K' for exiting a runlevel. The number after 'S' and 'K' indicate the order in which scripts are run. Best thing to do is look at existing scripts and links in those directories.

As for user space applications on boot, I usually use the inittab or runlevel method on the file system. I don't know of any way to put a user space app into the kernel uImage file. I'm sure somebody has figured out how.