结合本人在PCIE
NTB/DMA最近的实际工作，总结了地址转换窗口扩展和驱动加载过程中碰到的主要问题和解决办法。
0、系统启动后看不到NTB设备
需要检查BIOS，在PCIE设置里面NTB芯片是否使能。这是因为针对不同的应用场景和客户需要，BIOS里面通常添加了Enable/Disable
NTB的选项。
1、如何扩展地址转换窗口
a.确定系统要求的地址转换窗口的范围和大小；
b.确保系统要求的地址转换窗口的范围和大能够被BIOS支持
c.从可用的BAR2/3和BAR4/5中选择未使用的或者可扩展的BAR；
d.更新NTB芯片中该决定该BAR大小的寄存器；
2、如何正确处理新的地址转换窗口大小
一般NTB的SDK包括驱动和应用程序，由于驱动设计的通用性，为了支持新的地址转换窗口和大小，通常只需要更新应用程序，主要需要改动的有以下几点：
a.根据新选用的BAR，更新应用程序中的NTB/DMA初始化工作。这是因为不同的BAR，通常对应一组不同的NTB设置、管理寄存器；
b.如果新的地址转换窗口大小超过2G(0x80000000)，需要检查表示大小的数据类型，它一定不能是有符号的32位整型数据，否则会表示成一个负数；如果新的地址转换窗口超过4G，务必确保表示大小的数据不能是32位整数。
3、如何正确计算地址偏移
在实际基于NTB的应用程序当中，需要透过转换后映射到本地用户态的地址，加上一个偏移去访问目的地址。此时，需要特别注意的是：如果址转换窗口大小超过2G(0x80000000)，需要检查表示偏移的数据类型，它一定不能是有符号的32位整型数据，否则会表示成一个负数；如果新的地址转换窗口超过4G，务必确保表示大小的数据不能是32位整数，而应该是64位整型数据类型。
4、加载驱动时发现Chip
ID/vendor ID不匹配，导致无法加载
在加载相同NTB芯片
相应的驱动的时候，在不同批次或者型号的板卡上有时会发现驱动加载失败，而在其他批次或者型号上可以加载，甚至在相同批次、型号的其他板卡上也能成功加载，碰到这种情况，如果驱动有debug模式的话可以先按照debug模式加载驱动，然后根据dmesg信息查看驱动失败的具体位置，结合驱动源代码查找根源。根据笔者的经验，在像NTB这种设置和EEPROM关系非常紧密的驱动，需要排除的一点就是出厂EEPROM设置的差异导致的驱动加载出错的情况。笔者就碰到两次在不同批次的机器上，分别由于NTB
EEPROM里对vendor
ID /device ID的错误设置导致驱动无法加载的情况。后来通过修改驱动，把要使用的板卡上的NTB的vendor
ID/device ID添加到驱动探测代码里，然后更新EEPROM到标准的设置才彻底解决。
5、驱动加载之后，应用程序仍然无法使用NTB设备
Linux内核驱动加载后，并不表示应用程序就一定可以立即使用硬件设备了，因为无论是字符设备、块设备还是流式设备，操作系统都需要向用户程序提供一个在应用态可以访问的设备节点
。在早期的Linux驱动的实现过程中，设备节点并不会由驱动程序自动建立启动，而是需要通过脚本或者输入mknod等命令建立起来。因此对于NTB驱动，同样要搞清楚它的设备节点是否需要手工建立。如果是，需要保证在应用程序使用之前，设备节点都已经存在，否则无法使用NTB设备。