海思3519使用AI棒遇到的问题

要想使用AI棒，最基本的环境是在插入AI棒是需要在\dev下创建一个指向AI棒（USB设备）的设备文件

最初在AI棒插入到海思3519开发板上时，只显示了一句话意思是识别了一个USB设备，但是发现在\dev下并没有创建出相应的设备文件，但是在\dev\bus\usb\003\下创建了一个文件经过查询发现，该文件实际上就是设备文件，其中189表示主设备号，在文件\proc\devices（如下图 左是主设备号，右是对应设备）里面发现189表示usb_device，276表示次设备号（主设备号代指一类设备，次设备号为这一类设备的某个特定设备，两者均由系统内核根据插入的设备分配）。                          

但是这个设备节点有个问题，那就是内核并没有给该设备文件规范一个特定格式的文件名，而是一个数字，且该数字会在每次拔插后逐次增加，名字一直在变化程序则无法使用。于是准备通过linux下一个很强大的设备文件管理工具udev来解决。在海思3519开发板上udev所在目录是\etc\udev\，该目录下有两个最主要的文件（文件夹）rules.d和udev.conf。udev.conf是个文件，从名字可以看出该文件设udev的配置文件，配置新创建的设备文件默认路径（\dev）及udev规则目录等东西，没有特殊情况不要随意修改该文件内容。rules.d是个文件夹，里面则存放着上面提到的udev所有的规则。所有的规则文件必须以“.rules”为后缀名。udev 按照规则文件名的字母顺序来查询全部规则文件，然后为匹配规则的设备管理其设备文件或文件链接。在规则文件里，除了以“#”开头的行（注释），所有的非空行都被视为一条规则，但是一条规则不能扩展到多行。规则都是由多个 键值对（key-value pairs）组成，并由逗号隔开，键值对可以分为 条件匹配键值对( 以下简称“匹配键 ”) 和 赋值键值对( 以下简称“赋值键 ”)，一条规则可以有多条匹配键和多条赋值键。匹配键是匹配一个设备属性的所有条件，当一个设备的属性匹配了该规则里所有的匹配键，就认为这条规则生效，然后按照赋值键的内容，执行该规则的赋值。

仅当操作符是“==”或者“!=”时，其为匹配键；若为其他操作符时，都是赋值键。

 

• RHEL5.3 里 udev 规则的所有操作符：

 

“==”：比较键、值，若等于，则该条件满足；

 

“!=”： 比较键、值，若不等于，则该条件满足；

 

“=”： 对一个键赋值；

 

“+=”：为一个表示多个条目的键赋值。

 

“:=”：对一个键赋值，并拒绝之后所有对该键的改动。目的是防止后面的规则文件对该键赋值。

 

• RHEL5.3 里 udev 规则的匹配键

 

ACTION： 事件 (uevent) 的行为，例如：add( 添加设备 )、remove( 删除设备 )。

 

KERNEL： 内核设备名称，例如：sda, cdrom。

 

DEVPATH：设备的 devpath 路径。

 

SUBSYSTEM： 设备的子系统名称，例如：sda 的子系统为 block。

 

BUS： 设备在 devpath 里的总线名称，例如：usb。

 

DRIVER： 设备在 devpath 里的设备驱动名称，例如：ide-cdrom。

 

ID： 设备在 devpath 里的识别号。

 

SYSFS{filename}： 设备的 devpath 路径下，设备的属性文件“filename”里的内容。

例如：SYSFS{model}==“ST936701SS”表示：如果设备的型号为 ST936701SS，则该设备匹配该 匹配键。

 

在一条规则中，可以设定最多五条 SYSFS 的 匹配键。

 

ENV{key}： 环境变量。在一条规则中，可以设定最多五条环境变量的 匹配键。

 

PROGRAM：调用外部命令。

 

RESULT： 外部命令 PROGRAM 的返回结果。例如：

 

1	PROGRAM=="/lib/udev/scsi_id -g -s $devpath", RESULT=="35000c50000a7ef67"

 

 

调用外部命令 /lib/udev/scsi_id查询设备的 SCSI ID，如果返回结果为 35000c50000a7ef67，则该设备匹配该 匹配键。

 

• RHEL5.3 里 udev 的重要赋值键

NAME：在 /dev下产生的设备文件名。只有第一次对某个设备的 NAME 的赋值行为生效，之后匹配的规则再对该设备的 NAME 赋值行为将被忽略。如果没有任何规则对设备的 NAME 赋值，udev 将使用内核设备名称来产生设备文件。

 

SYMLINK：为 /dev/下的设备文件产生符号链接。由于 udev 只能为某个设备产生一个设备文件，所以为了不覆盖系统默认的 udev 规则所产生的文件，推荐使用符号链接。

 

OWNER, GROUP, MODE：为设备设定权限。

 

ENV{key}：导入一个环境变量。

 

• RHEL5.3 里 udev 的值和可调用的替换操作符

 

在键值对中的键和操作符都介绍完了，最后是值 (value)。Linux 用户可以随意地定制 udev 规则文件的值。例如：my_root_disk, my_printer。同时也可以引用下面的替换操作符：

 

$kernel, %k：设备的内核设备名称，例如：sda、cdrom。

 

$number, %n：设备的内核号码，例如：sda3 的内核号码是 3。

 

$devpath, %p：设备的 devpath路径。

 

$id, %b：设备在 devpath里的 ID 号。

 

$sysfs{file}, %s{file}：设备的 sysfs里 file 的内容。其实就是设备的属性值。
例如：$sysfs{size} 表示该设备 ( 磁盘 ) 的大小。

 

$env{key}, %E{key}：一个环境变量的值。

 

$major, %M：设备的 major 号。

 

$minor %m：设备的 minor 号。

 

$result, %c：PROGRAM 返回的结果。

 

$parent, %P：父设备的设备文件名。

 

$root, %r：udev_root的值，默认是 /dev/。

 

$tempnode, %N：临时设备名。

 

%%：符号 % 本身。

 

$$：符号 $ 本身。

 

说明替换操作符的规则例子

1 2	KERNEL=="sd*", PROGRAM="/lib/udev/scsi_id -g -s %p", \ RESULT=="35000c50000a7ef67", SYMLINK="%k_%c"

 

该规则的执行：如果有一个内核设备名称以 sd 开头，且 SCSI ID 为 35000c50000a7ef67，则为设备文件产生一个符号链接“sda_35000c50000a7ef67”.

 

简单说明键值对的例子：

1	KERNEL=="sda", NAME="my_root_disk", MODE="0660"

 

KERNEL 是匹配键，NAME 和 MODE 是赋值键。这条规则的意思是：如果有一个设备的内核设备名称为 sda，则该条件生效，执行后面的赋值：在 /dev下产生一个名为 my_root_disk的设备文件，并把设备文件的权限设为 0660。

通过学习udev的规则，于是在rules.d目录下创建了第一个自己的规则文件12-ai-usb.rules

内容为 SUBSYSTEM=="usb"：表示子系统名为usb，（通过26个字母一个个试出来的）

 ATTR{idVendor}=="03e7", ATTR{idProduct}=="2150"：分别表示设备ID，高位为03e7，低位为2150，该值通过lsusb查询

SYMLINK+="ai_u"：表示满足上面几个条件的设备则创建一个名字为ai_u的链接文件

MODE:="0600"：表示上述创建的链接文件的权限为600

新建好上面的规则后再插拔AI棒，则在\dev下创建了一个链接文件于是欣喜若狂，成功了吗，反正至少解决了名字变换的问题。于是将编译好的示例程序run_cpp、libmvnc.a 、libusb-1.0.a等文件放进去，运行run_cpp，果然没成功。不仅没成功，我的设备文件ai_u也没了。闹哪样？？？

然后又继续上网查找，发现有一个赋值键NAME，这个键是利用匹配到设备的主、次设备号创建一个新的设备文件，也就是一个设备文件将由两个设备文件同时指向同一个设备，于是将前面规则中的SYMLINK+="ai_u"改为NAME="ai_u"，再插拔一下，识别到AI棒时多了一句话，意思为创建的设备名字和内核识别的不同，请改为用SYMLINK+=或者修改名字，应该影响不大，然后再跑一下示例程序果然还是不行。创建的设备文件ai_u也没有，最后发现执行lsusb时，发现设备ID变了，由原来的03e7:2150变成了03e7:bf73，嗯？？？这是为什么？没办法看libusb.a的源码吧，突然灵光一现，我只用来匹配设备ID高为呢，因为低位变了高位并没有变，抱着试试的小心思将规则改成了，再插拔一下，运行run_cpp，成功了！！！ 回头再看设备ID，反而没有变。幸福来的太突然了，经过了将近两周的时间，设备AI棒的使用结束。