u-boot的任务是启动内核，内核的任务是启动应用程序 ,应用程序会涉及很多文件和硬件操作（当然不会直接操作硬件），比如读写文件，点灯、获取按键值。
比如对于控制led灯的用户程序与驱动程序,最简单的实现方法是:
应用程序中需要打开led灯，就需要open函数,在内核中的驱动程序中也有对应的led_open函数，这个led_open函数就是用来负责初始化led的引脚功能,应用程序中要调用read函数读取led灯的状态，内核中的驱动程序也有led_read函数。这是应用程序与内核中驱动程序一种最简单的对应方式.
那么应用程序中的open、read函数最终怎样调用到驱动程序中的led_open、led_read呢，中间有哪些东西?
在linux中共有4层软件,如下图:
应用程序:就是被调用的那些库函数，例如open、read、write... ...
C库(系统调用):其中的其实就是实现open、read这些函数来调用swi val 指令进入内核(函数不同val值都会不同)
内核: 内核根据swi后面不同的值去调用VFS中的system_open/system_read/ system_write等异常处理函数 找到相应的驱动程序(VFS:virtual file system 虚拟文件系统)
例如:
int main() { int fd1 fd2; int val=1; fd1 = open(“/dev/led”,O_RDWR); //打开led write(fd1, &val, 4); fd2 = open(“hello.txt”,O_RDWR); //打开文本 write(fd2, &val, 4); }
上面的应用程序主要实现点灯与打开文本文件，都是用的同样的函数。但是点灯与打开文本文件的行为显然不一样。那么谁来实现这些不一样的行为呢？
对于LED灯，有led_open驱动程序。对于文本文件存在于flash设备上，也有对于的驱动程序。system_open、system_read最终会根据打开的不同文件，找到底层的不同驱动程序，然后调用驱动程序中的硬件操作函数，比如led_open来实现对具体硬件设备的操作。
这就是整个的字符设备驱动程序框架。
例如LED,如下图:
在应用层应用程序中有open、read、write
同样，在驱动程序中也对应有led_open、led_read、led_write
剩下的就是驱动框架了。