系统探测（exploration）和初始化
1 介绍
探测和初始化RapidIO系统有一些基本的方法，最简单的方法是定义系统各部件的上电状态，这样，各设备能对系统其余部分的有关通讯方面的知识有足够的了解，这通常是在系统boot期间，从串行ROM或类似的器件中将初始化信息读出并以此初始化所有设备，这种方法非常适合于那些不变的静态系统以及对boot有严格时间要求的系统。第二种方法是在BOOT时由一个处理器来探测和配置系统，这可能导致比较长的boot时间，但是这么做更灵活，可支持那些即插即用经常改变的系统。
2 Boot代码存取
在大部分RapidIO应用中，系统初始化要求有用于探测和初始化器件的软件，系统初始化通常由一个处理器或一组处理器来执行，处理器的boot代码可以放在本地ROM里，也可以在一个远程代理器件那里，因为系统还没有初始化，这时，如果boot代码存放在远程代理器件那儿，我们需要一个特殊的方法让处理器通过一个还没有初始化的系统来存取到boot代码。
在复位之后，处理器通常向一个固定的地址发出代码存取请求，在处理器和RapidIO架构之间的代理硬件要求能够接收这个请求，自动将它映射成NREAD交易，这个交易以一个适当的地址偏移被映射到一个专用的器件ID上以便发现Boot代码。在处理器和存放有boot ROM的代理器件之间的所有器件应该有个缺省状态，都会将这个NREAD交易路由到Boot ROM器件，并把其响应路由回处理器。存有boot代码的代理器件的器件ID是0xFE（0x00FE），处理器缺省器件ID是从0x00开始，逐渐增加，顺序分配的。因为需要取boot代码的的都HOST，而HOST是系统设计的时候就确定的，其ID也是设计时就是这么分配好了。
图2-1显示了带有boot ROM系统的一个例子，boot ROM存在一个代理器件上，在处理器和代理之间的交换器件的缺省路由状态应该是将所有对器件ID为0xFE的请求路由到代理器件，并将从代理那儿获得所有的响应包返回给处理器。这意味着交换机必须知道取boot代码的处理器的器件ID，处理器的器件ID是从0x00开始的。对于图2-2的例子，系统处理器缺省器件ID为0x00，交换机的缺省状态是路由器件ID=0x00到port 2。
一旦处理器能开始运行boot代码，它就开始执行系统余下的探测和初始化。
3 探测和初始化
作为一个例子，算法仅考虑一个简单系统：仅一个处理器负责这个系统的探测和初始化，我们称这个处理器为Host，探测和初始化过程也是基于一定的规则，部件和系统设计者应该遵从这个规则。
7.3.1 探测和初始化规则
- Host应该能够“到达”它负责初始化的所有代理器件，这可能要求一些机制能够产生第三方交易以达到那些不是透明可见的器件。
- 由代理和交换器件产生的维护响应应该送到收到维护请求的那个端口。例如，一个器件实现了一个5端口的交换，系统Host发布一个维护读请求给交换器件，它在输入端口3收到这一请求，随后产生这个维护读请求的响应，交换芯片必须将它路由到它的输出端口3，即使交换芯片可能缺省配置成路由响应到非端口3（当交换机芯片被配置的时候，它也应当将响应路由到端口3）。
- 所有器件都有CSRs，以辅助探测和初始化过程，这个例子里使用的寄存器包含了下面信息：
- Base Device ID寄存器：这里存放的是器件缺省的器件ID，它是CSR空间里的标准寄存器，偏移地址是0x60，上电时，所有的代理器件缺省器件ID为0xFF（0xFFFF）（boot代码器件为0xFE，Host是从0x00开始），一个器件可能有多个器件ID，但是只有这个寄存器定义的ID用于探测和初始化。
- Master Enable位：上电复位时，这一位缺省状态是：代理为0，Host为1。这一位位于通用控制CSR在块偏移0x3C处，如果master为0，器件不允许发布请求，仅允许接收请求产生响应。这一位由Host使用，用来控制代理什么时候允许向系统发布交易，交换器件缺省是允许发布请求的，所以它没有这一位。
- Discovered位：上电复位时，这一位缺省状态是：代理为0，Host为1。它位于物理层端口通用控制CSR，在块偏移0x3C处，当Host通过探测机制发现该设备后，Host会将该设备这一位设置这一位为1，Discovered位对检测路由环和热插拔环境是有用的，
7.3.2 探测和初始化算法
如果满足上面的规则，所有的代理器件都能被Host存取的：或者作为endpoint（它对来自Host的维护交易做出响应），或者作为交换器件（通过hop_count机制）。
基本算法是探测系统，依次探测系统中的每个endpoint，首先定位相邻器件，方法是向器件ID为0xFF及hop count等于0x00的器件发送维护读命令。这保证引起相邻器件做出响应，然后配置器件的基本器件ID为独一无二的，从而可以寻址下个设备，并建立路由表。
当所有系统里的所有器件都被标识并具有独一无二的基本器件ID时（没有任何器件的基本器件ID值为0xFF），Host能完成最后的器件分配和配置，以满足应用的要求，并使能代理器件可以发布请求。
补充知识：维护包的路由：
在交换网络中路由维护包是件困难的事情，因为交换器件可能没有自己的器件ID，对于这些器件，维护包的替代寻址方法是在包中使用一个附加的hop_count域，用来表示这个包在网络中自打发布以来被交换的次数。当没有关联的器件ID的交换机接收到维护包时，它会检查hop_count域，如果接收的hop_count是0，表示这个存取是对这个交换器自己的，如果不是0，会将它减1，并按照包的目的ID域送出，这个方法允许对任何两个可寻址处理单元之间路径上的intervening switches进行简单的存取，然而，因为维护响应包总是指向endpoint，hop_count域应该总是被包的源设为0xFF，以防止它们冒被干扰器件接收的危险。图1-4显示增加到维护逻辑包上的属于传输层的域。
维护逻辑包如图3-4。前面已经描述过逻辑层维护包
7.3.3 探测和初始化例子
图2-3显示的是先前介绍的一个单Host小系统。
按照上面定义的规则，除了Host和Boot ROM器件外，在复位后，所有的基本器件ID都是0xFF，Host的Master Enable和Discovered位置1，代理器件的Master Enable和Discovered清0。
首先，设计人员会将Host的Base device ID置为0。
然后，发现相邻的器件。为此，Host发送维护读：器件ID = 0xFF，hop_count = 0和偏移是0x00_0000。因为hop_count = 0，所以，switch接受这个请求，会将它的Device Identity和Information CARs返回到请求来自的端口。按照返回的信息，Host上的软件能识别出它是个switch，Host然后读switch的offset 0x00_0010 word 1处的端口信息CAR，据此可以发现哪个端口连接有设备，响应表达了这是一个4端口switch（Host可能通过设备信息寄存器已经知道了这个信息），host连接在port2上。
Host然后检查switch的缺省路由表：switch找到boot 器件ID=0xfe的端口路由，以便它能够保留boot code路径（这个路径此时可能还在运行），发现boot器件连接在switch的端口1，Host还将switch的Discovered位置位。
补充知识：
Device Identity CAR (Offset 0x0 Word 0):
|
Bit |
Field Name |
Description |
|
0-15 |
DeviceIdentity |
是厂家表示器件类型的独一无二的标识，这个编号是厂家管理的。 |
|
16-31 |
DeviceVendorIdentity |
器件厂家的独一无二标识，这个编号是RapidIO国际组织管理的 |
Device Information CAR(Offset 0x0 Word 1):
|
Bit |
Field Name |
Description |
|
0-31 |
DeviceRev |
器件的版本级别，这个编号是厂家管理的。 |
Switch Port Information CAR（Offset 0x10 Word1）
|
Bit |
Field Name |
Description |
|
0-15 |
--- |
保留 |
|
16-23 |
PartTotal |
在处理单元上的端口个数。0-保留，其它表示总的端口个数 |
|
24-31 |
PortNumber |
端口号，存取这个寄存器的维护读操作来自这个端口，端口号起始于0x00 |
下一步，通过hop_count=0x00的维护写请求，Host配置switch路由器件ID=0xFF到port 0，器件ID=0x00到port 2（因为boot器件在系统里，所以这个路由关系可能已经配置好），然后，Host发布另一个维护读请求，这次器件ID = 0xFF，hop_count = 0x01，switch发现它不是维护请求包的最终目的地，它会将hop_count减1，路由到端口0，这个端口连接有代理器件，代理器件响应，switch通过port 2将包给器件ID=0x00（Host），再一次，软件标识该器件，将它的Discovered位设为1，按要求配置它，将它的基本器件ID分配为0x01。
Host然后修改路由表为现在的路由：将器件ID = 0x01路由到端口0，因为boot器件定位在端口1，所以不是修改路由表将器件ID=0xff路由到端口1，而是Host发布器件ID=0xFE（boot器件）及hop_count=0x01的维护读操作，响应标识了有代理在端口1上，置位代理的Discovered位，如果有必要就配置它，保持其base Device ID = 0xFE，以便Host能继续执行boot code。
下一次迭代是：Host设置switch路由表，将器件ID=0xFF路由到端口3（因为这时Host已经知道自己连接在端口2上），如前述一样，Host发布维护读交易。
在终点，代理仅请求的CAR信息，Host现在知道探测完成了，因为架构中没有其它路径了，最终完成如图2-8所的系统配置，代理器件能使它们的Master Enable位，以便它们可以向已经初始化好的系统中发布交易，当Host完成执行boot Rom中的代码后，如果要改变boot器件ID也是允许的。
这个过程的变种也是有可能的，例如，一个系统可能希望在探测结束之前就使能某些器件。
具有多个Hosts的更复杂系统，失败的Host恢复，热插拔需求能够用更复杂算法去寻址，使用标准寄存器在CSR空间里的偏移为0x68和0x6C的Host Base Device ID Lock Register和Component Tag Registe。