说明

点击数：4013

• vxworks 6.x
• device driver
• vxbus

作者：Escorpion

VxBus是指在 VxWorks 中用于支持设备驱动的特有的架构，这种架构包含对minimal BSP的支持。它包括以下功能:

1. 允许设备驱动匹配对应设备
2. 提供驱动程序访问硬件的机制
3. 软件其他部分访问设备功能
4. 在VxWorks系统中，实现设备驱动的模块化

VxBus是Vxworks的模块化机制，类似于linux中的module。通过VxBus可以对模块方便的裁剪或者添加。VxBus 在总线控制器驱动程序服务的支持下，能在总线上发现设备，并执行一些初始化工作，使驱动与硬件设备之间正常的通讯。

vxBus下对设备管理做了更为详细的划分，简单说来，硬件称为device，软件叫做driver。如果一个device出现在硬件列表中，启动时需要到driver的队列中去找相应的driver，如果找到，二者结合成一个instance，否则在vxBusShow里可以看到一个orphan。使用vxBusShow可以比较清晰的看到driver列表和device列表以及orphan列表。

相关参数

设备注册：vxbDevRegister(structure vxbDevRegInfo *pDevInfo)

显然，我们唯一要做的就是填充vxbDevRegIndo *pDevInfo结构体，其定义如下

struct vxbDevRegInfo

{

    struct vxbDevRegInfo * pNext;

    UINT32  devID;

    UINT32  busID;

    UINT32  vxbVersion;

    char    drvName[MAX_DRV_NAME_LEN+1];

    struct drvBusFuncs * pDrvBusFuncs;

    struct vxbDeviceMethod * pMethods;

    BOOL (*devProbe) ( struct vxbDev * pDevInfo);

    struct vxbParams * pParamDefaults;

};

参数解释：

阅读全文: 基于VxWorks的VxBus字符设备驱动

说明

点击数：2108

一．MUX中间层

为了能够兼容更多的网络设备和网络协议，VxWorks操作系统专门在网络设备驱动程序和网络协议层之间增加了MUX接口层。网络设备驱动程序不关心用户通过何种网络协议访问设备，只需要将数据传递给MUX层，或者从MUX层获取需要发送的数据；同样，协议层中的协议也不需要关心用户使用何种网络设备，将数据发送给MUX层或者从MUX层读取数据即可。

MUX层位于数据链路层和网络协议层之间，它提供协议和设备的衔接，管理着网络协议接口和底层设备驱动之间的通信。

MUX层的加入有效隔离了网络设备驱动程序和协议层协议， MUX层的统一标准接口屏蔽了底层网络设备的差异性和上层网络组件的特殊性，降低了网络设备的增加和网络组件的扩展的复杂度。

二．END & NPT

MUX层支持两种网络设备驱动程序：END（Enhanced Network Driver）和NPT（Network Protocol Toolkit）。

这两种网络设备驱动程序的大体结构相似，与MUX接口也几乎相同，MUX装载两者的方式也相同。不同的是，END模型基于帧（frame）传递数据，NPT模型基于包（packet）传递数据。在这里，帧和包的区别在于，帧包含了网络传输的全部数据，也就是数据包和MAC地址等链路层数据；而包仅仅包括数据包，不包括链路层信息。

NPT驱动程序模型可以看作是对END模型的一个扩展。END模型是VxWorks推荐的实现方式。

阅读全文: VxWorks网络设备的加载及协议栈初始化

说明

点击数：2808

• vxworks
• vxbus

VxWorks 6.x引入了新的vxbus的驱动架构，对于用惯了VxWorks 5.x的朋友来说，确实有点不习惯，本文简单介绍如何在vxworks系统下使用vxbus，希望对于初学vxbus架构的朋友有所帮助！

vxBus模块添加

VxVorks中采模块化的方式管理各个功能单元，驱动也是由一个或多个模块组成。VxBus是vxworks中的模块化机制。类似于linux中的module。通过vxBus我们可以方便的裁剪或添加新的模块。

模块的裁剪通常是在vxworks的开发环境workbench中进行的。建立一个工程后，会得到一个config文件，通过鼠标操作就可以实现模块的裁剪。

添加新模块则复杂一些，需要添加几个新的文件，但内容很简单，只是用来设置一些必须的信息。添加完成后，就可以像标准模块一样裁剪了。添加模块的详细过程可以再workbench中的vxbus的pdf文档中得到，说的很详细。

vxBus驱动注册过程

vxbus驱动的注册通过vxbDevRegister实现。其原型如下：

STATUS vxbDevRegister
    (
    struct vxbDevRegInfo * pDevInfo /* per-bus recognition info */
    )

显然，我们唯一要做的就是填充结构体pDevInfo，其类型定义如下：

struct vxbDevRegInfo
{
    struct vxbDevRegInfo * pNext;
    UINT32  devID;
    UINT32  busID;
    UINT32  vxbVersion;
    char    drvName[MAX_DRV_NAME_LEN+1];
    struct drvBusFuncs * pDrvBusFuncs;
    struct vxbDeviceMethod * pMethods;
    BOOL (*devProbe) ( struct vxbDev * pDevInfo);
    struct vxbParams * pParamDefaults;
};

devProbe用于设备probe设备。检测当前是否有该类型设备。如果不需要进行probe，则可以设为NULL。

pNext用于总线级联。如一个挂在网卡上的网卡，其phy通过mii与mac相间接。我们要访问phy，则需要先通过pci总线访问mac，在通过mii总线访问phy。有点类似先做汽车到县城，再转驴车到村子。这里的pNext就是告诉你下面该转驴车了。如果没有级联，则设为NULL。 pMethods用于提供了总线的各种方法，但实际上通常只提供该总线特有方法。因为通用方法，如open、read等，一般都是通过io层的system call调用的，他们需要单独注册。

pDrvBusFuncs提供了设备初始化需要的几个接口，一共有三个：

阅读全文: VxWorks中的vxbus使用入门

说明

点击数：1966

• vxworks
• trueffs

1、Wear-Leveling

闪速存储器不能无限次重复使用。它的每个扇区的擦除次数虽然很大，但却有限；因此，随着使用次数的加长，它最终会变成只读状态，所以应该尽最大可能延长它的寿命。行之有效的方法就是平衡使用所有的存储单元，而不让某一单元过度使用。这种技术被称之为损耗均衡。TrueFFS使用一种基于一张动态维护表的存储器——块映射的翻译系统来实现损耗均衡技术。当块数据被修改、移动或碎片回收后，这张维护表会自动调整。然而，如果存储在Flash上的一些数据本质上是静态的，就会产生静态文件锁定问题。存储这些静态数据的区域根据不会被轮循使用，其它区域就会被更频繁地使用，这将降低Flash期望的生命值。TrueFFS通过强制转移静态区域的方法成功克服了静态文件锁定问题。因为映射表是动态的，TrueFFS能够以对文件系统不可见的方式转移这些静态数据区域。由于绝对强制损耗均衡方式会对性能产生一些负面影响，所以TrueFFS采取了一种非绝对损耗均衡算法。它保证了所有空间的使用近似平等而不影响性能。

2、 碎片回收

块数据的修改使得Flash的一些块区域中的数据不再有效，并且这些区域在擦除之前变得不可写。如果没有机制来回收这些区域，Flash很快就会变成只读的状态了。不幸的是由于这些块不可能单独擦除，回收这些块就有些复杂了。单次擦除被限制在一个叫作擦除单元的较大范围内，如对于AMD的Am29LV065D芯片来说是64KB。TrueFFS使用一种被称为碎片回收的机制来回收那些不再包含有效数据的块。该机制从一个预擦除单元内复制所有的有效数据块到另一个新的被称为转移单元的擦除单元。然后，TrueFFS更新映射表，再擦除这个废旧的预擦除单元。这样，原来的块出现在外界时仍然包含了原来的数据，虽然这些数据现在已经存放在Flash存储器的其它空间。

碎片回收算法会找到并回收与下面标准最吻合的擦除单元：

• 废块最多
• 擦除次数最少
• 最静态的区域

3、 块分配和关联数据集结

为了提高数据的读取效率，TrueFFS使用一种灵活的空间分配策略：将关联的数据（如由同一个文件的内容组成的多个块）集结到同一个单独擦除单元内的一段连续的区域中。为此，TrueFFS尽量在同一个擦除单元内维持一个由多个物理上连续的自由块组成的存储池。如果这样连续的存储池无法实现，TrueFFS分尽量保证池中的所有块是在同一个擦除单元内。如果连这样的情况也不可能的话，TrueFFS会尽量把块池分

配到一个拥有最多可用空间的擦除单元内。这种集结关联数据的途径有几个好处。首先，如果TrueFFS必须从一个小的存储窗口来访问Flash,那么这样集结了的关联数据可以减少调用映射物理块到该窗口的次数，加快了文件继续访问速度。其次，这种策略可以减少碎片的产生。这是因为删除一个文件可以释放掉更容易回收的完整块，意味着碎片回收会变得更快。另外，它可以使属于静态文件的多个块存放在同一地址，这样当损耗均稀算法决定移动静态区域时，转移这些块就变得更加容易了。

4、 Power Failure Management

向Flash写数据有时可能会出错，比如在响应文件系统写请求时、碎片回收期间甚至在TrueFFS格式化或擦除Flash时。在这些情况下，TrueFFS能够从错误中恢复过来；但在新数据第一次写入Flash时如果出错就会丢失这些数据。然而，TrueFFS非常仔细地保证所有已经存放在Flash上的数据是可恢复的，甚至能够避免用户由于不耐烦或好奇而猛地拔出Flash卡而可能造成的灾难性后果。

TrueFFS algorithms based on “erase after write” instead of"erase before write"健壮的关键是它使用了一种“先写后擦”的策略。当更新Flash一个扇区的数

据时，只有在更新操作完成并且新存储的数据校验成功后，先前的数据才会被允许擦掉。这样的结果是数据扇区不能处于部分写状态。操作成功的话新扇区的数据有效，否则老扇区的数据有效。很明显，这样有利于用户已经写到Flash上的数据的稳定性”