uboot驱动模型(DM)分析(一)

uboot版本:uboot-201711

要分析uclass之前,首先得搞清楚两个宏U_BOOT_DRIVER及U_BOOT_DEVICE的作用:

1.U_BOOT_DRIVER及U_BOOT_DEVICE宏定义如下:

 1 #define U_BOOT_DRIVER(__name)                        \2     ll_entry_declare(struct driver, __name, driver)3 4 #define U_BOOT_DEVICE(__name)                        \5     ll_entry_declare(struct driver_info, __name, driver_info)6 7 #define ll_entry_declare(_type, _name, _list)                \8     _type _u_boot_list_2_##_list##_2_##_name __aligned(4)        \9             __attribute__((unused,                \
10             section(".u_boot_list_2_"#_list"_2_"#_name)))

下面具体分析如下:

例如:

 1 U_BOOT_DRIVER(serial_s5p) = {2     .name    = "serial_s5p",3     .id    = UCLASS_SERIAL,4     .of_match = s5p_serial_ids,5     .ofdata_to_platdata = s5p_serial_ofdata_to_platdata,6     .platdata_auto_alloc_size = sizeof(struct s5p_serial_platdata),7     .probe = s5p_serial_probe,8     .ops    = &s5p_serial_ops,9     .flags = DM_FLAG_PRE_RELOC,
10 };

根据上述宏定义展开得到:

 1 ll_entry_declare(struct driver, serial_s5p, driver)2         struct driver _u_boot_list_2_driver_2_serial_s5p __aligned(4) __attribute__((unused, section(".u_boot_list_2_driver_2_serial_s5p"))) = {3             .name    = "serial_s5p",4             .id    = UCLASS_SERIAL,5             .of_match = s5p_serial_ids,6             .ofdata_to_platdata = s5p_serial_ofdata_to_platdata,7             .platdata_auto_alloc_size = sizeof(struct s5p_serial_platdata),8             .probe = s5p_serial_probe,9             .ops    = &s5p_serial_ops,
10             .flags = DM_FLAG_PRE_RELOC,
11         };

从上面我们可以看到声明他们的时候对它们做了如下要求：

1.要求它们存放的时候4字节对齐，这通常是为了更方便的访问处理它们；
2.要求它们存放在一个各自独有的段里面

在链接脚本arch/arm/cpu/u-boot.lds中有如下定义:

1 . = ALIGN(4);
2             .u_boot_list : {
3             KEEP(*(SORT(.u_boot_list*)));
4      }

所有以.u_boot_list开头的段多将在这里存放,KEEP关键字是为了保证所有的段多被加进来，不要被链接器自作聪明的把某些它认为没有的段舍弃;
用宏U_BOOT_DRIVER和U_BOOT_DEVICE声明的变量将被分配到自己一个特有的段下，在链接的时候被组织到一起,具体可以在uboot编译成功后生成的u-boot.map中查看到u_boot_list段的相关信息如下:

注意到u_boot_list_2_driver_1和u_boot_list_2_driver_3,这段地址范围内即为驱动函数列表集合

搞清楚这两个关键宏后下篇将具体分析uclass,uclass_driver,udevice,driver之间的关系

uboot驱动模型(DM)分析(一)相关推荐

linux 内核驱动模型,linux设备驱动模型架构分析一
linux设备驱动模型架构分析一发布时间:2018-07-04 15:14, 浏览次数:584 , 标签: linux 概述 LDD3中说:"Linux内核需要一个对系统结构的一般性描述 ...
uboot usb驱动模型
关于uboot驱动模型,这篇文章讲得很好,不再描述: [uboot] (番外篇)uboot 驱动模型_ooonebook的博客-CSDN博客 U-Boot Driver Model领域模型设计 lin ...
linux内核部件分析之——设备驱动模型之class
前面看过了设备驱动模型中的bus.device.driver,这三种都是有迹可循的.其中bus代表实际的总线,device代表实际的设备和接口,而driver则对应存在的驱动.但本节要介绍的class ...
linux内核部件分析(十)——设备驱动模型之class,linux内核部件分析（十）——设备驱动模型之class...
前面看过了设备驱动模型中的bus.device.driver,这三种都是有迹可循的.其中bus代表实际的总线,device代表实际的设备和接口,而driver则对应存在的驱动.但本节要介绍的class ...
char添加一个字符_LINUX字符设备驱动模型分析（起始篇）
在前面几个模块的介绍中,我们主要以vfs为起始,完成了sysfs.设备-总线-驱动模型.platform设备驱动模型.i2c设备驱动模型.spi设备驱动模型的分析.在对这些模块进行分析的时候,我们或多 ...
从串口驱动到Linux驱动模型
大学的时候,帮朋友写的操作系统调研的作业,最近整理过去的文档时候偶然发现,遂作为博客发出来. 从串口驱动到Linux的tty子系统驱动模型简要分析基于ARM920T核心 Samsung的S3C244 ...
uboot驱动之udevice
struct udevice --> driver的一个实例该结构保存关于设备的一些信息,这个设备是驱动绑定的某个端口或外设,在本质上它也还是个driver实例. 可通过调用bind函数创建一 ...
设备驱动模型之class
前面看过了设备驱动模型中的bus.device.driver,这三种都是有迹可循的.其中bus代表实际的总线,device代表实际的设备和接口,而driver则对应存在的驱动.但本节要介绍的class ...
u-boot下的DM驱动模型
U-boot 下DM驱动模型的相关笔记要注意的关键两点: DM驱动模型的一般流程bind->ofdata_to_platdata(可选)->probe 启动,bind操作时单独完成的,主 ...
Uboot中的DM驱动模型
这一篇我们学习uboot中的驱动模型的初始化,在uboot中,驱动模型被称为Driver Model,简称DM.这种驱动模型为uboot中的各类驱动提供了统一的接口. 1. 数据结构及概念 DM模型主 ...

uboot驱动模型(DM)分析(一)

uboot驱动模型(DM)分析(一)相关推荐

最新文章

热门文章