PowerPC上的扁平设备树文件和Open Firmware是什么关系？

看了一天，还不太明白，简单说一下自己的理解吧 对于Power, Sparc等有些系统存在Firmware（类似于BIOS吧）引导OS，后来sun，ibm等几家出了一个标准IEEE 1275，标准化一系列接口（Open Firmware），希望一个内核镜像可支持多平台等。 随着linux内核arch/ppc和arch/powerpc整合，内核实现了Open Firmware API，于是ePAPR引进了遵循（但不是完全遵循）此标准的device tree来描述相关板子外围信息。 额，标准还在发展中，历史资料好难找啊，以上不能保证完全正确。

赞耐心研究 顺道帮你顶顶，不定有人能看到 【 在 yihang (Goodluckfly) 的大作中提到: 】 : 看了一天，还不太明白，简单说一下自己的理解吧 : 对于Power, Sparc等有些系统存在Firmware（类似于BIOS吧）引导OS，后来sun，ibm等几家出了一个标准IEEE 1275，标准化一系列接口（Open Firmware），希望一个内核镜像可支持多平台等。 : 随着linux内核arch/ppc和arch/powerpc整合，内核实现了Open Firmware API，于是ePAPR引进了遵循（但不是完全遵循）此标准的device tree来描述相关板子外围信息。 : ...................

【 在 yihang 的大作中提到: 】 : 看了一天，还不太明白，简单说一下自己的理解吧 : 对于Power, Sparc等有些系统存在Firmware（类似于BIOS吧）引导OS，后来sun，ibm等几家出了一个标准IEEE 1275，标准化一系列接口（Open Firmware），希望一个内核镜像可支持多平台等。 : 随着linux内核arch/ppc和arch/powerpc整合，内核实现了Open Firmware API，于是ePAPR引进了遵循（但不是完全遵循）此标准的device tree来描述相关板子外围信息。 : ................... 内核移植时 本身是可以配置启动参数的 这样参数就固定了 不灵活 但是通常情况下并不这样做 而是通过uboot来传递启动参数 另外还有很多参数是通过bd info这样的结构体来传递的 这样同一个内核映像可以适应多种不同的板级配置 但是这些参数仍然是有限的 并且bd info在内核和uboot中需要保持一致 当PPC CPU类型越来越多时 这个结构体的维护就变得越来越复杂 为了适应这种情况 需要提供更灵活的机制来传递更多的板级配置参数 于是非标准化的open firm引入了PowerPC平台 将系统可变的大部分参数从内核中隔离出来 作为单独的设备树 内核启动时 再通过uboot传递给内核 这样同一个内核可以适应各种不同的配置 移植性也更强 更简单

[QUOTE] 【 在 ssailing 的大作中提到: 】 : 内核移植时 本身是可以配置启动参数的 这样参数就固定了 不灵活 : 但是通常情况下并不这样做 而是通过uboot来传递启动参数 : 另外还有很多参数是通过bd info这样的结构体来传递的 : ................... [/QUOTE] 呵呵，太赞了。 一直等你们呢。 有没有标准变化等相关的历史资料呢，比如啥时候提出的？啥时候建立标准。 内核的版本啥时候引入Open Firmware API的？ U-Boot是不是1.3.0引入的对FDT blob的支持的？

【 在 yihang 的大作中提到: 】 : [QUOTE] : [/QUOTE] : 呵呵，太赞了。 : ................... 兄弟还没消息啊 听manager说又确定了一些offer 已经通知人力了 等等吧 下周应该有消息

[QUOTE] 【 在 ssailing 的大作中提到: 】 内核移植时 本身是可以配置启动参数的 这样参数就固定了 不灵活 但是通常情况下并不这样做 而是通过uboot来传递启动参数 另外还有很多参数是通过bd info这样的结构体来传递的 这样同一个内核映像可以适应多种不同的板级配置 但是这些参数仍然是有限的 并且bd info在内核和uboot中需要保持一致 当PPC CPU类型越来越多时 这个结构体的维护就变得越来越复杂 为了适应这种情况 需要提供更灵活的机制来传递更多的板级配置参数 于是非标准化的open firm引入了PowerPC平台 将系统可变的大部分参数从内核中隔离出来 作为单独的设备树 内核启动时 再通过uboot传递给内核 这样同一个内核可以适应各种不同的配置 移植性也更强 更简单 [/QUOTE] 作用你已经说了。 我还有几个疑问。也补充一下我前面说的 较新的内核中加入了Open Firmware API（哪个版本？2.6.22 or 2.6.25? 求证） IBM PowerPC pSeries，Apple PowerPC，Sun SPARC等均采用的是Open Firmware；Open Firmware能在运行时构建板子信息（Device tree）直接传递给了内核，内核利用OF扫描设备树获取设备信息。 Embedded PowerPC中一般采用u-boot等bootloader，而不是采用Open Firmware，而u-boot以前采用的bd_t不再和内核兼容，所以引入了一个单独的Flatten device tree（非标准Open Firmware）传给内核以其描述板子信息，并保持了和内核的兼容一致。 IBM，sun等制定IEEE 1275标准的目的有：加速支持包的驱动等软件开发，减少硬件带来的变化需求和成本，减少对内核设计和编译的需求。 很久之前看到过一个资料，说IBM为了自己Power服务器的升级和设置方便，提出了Open Firmware，并逐渐推动IEEE 1275标准的制定（98年？）

【 在 ssailing 的大作中提到: 】 : 兄弟还没消息啊 : 听manager说又确定了一些offer 已经通知人力了 : 等等吧 下周应该有消息 ericsson? 已经通知了 现在正赶紧忙论文呢，完成项目。争取年前学校的毕业事宜结束 : )

【 在 yihang 的大作中提到: 】 : ericsson? 已经通知了 : 现在正赶紧忙论文呢，完成项目。争取年前学校的毕业事宜结束 : ) 恭喜～

你说的uboot通过bd_t传参给内核的内容我很感兴趣 我们之前项目中，进行系统移植时，uboot版本是1.1.1，linux是2.6.13，因为CPU是ppc405EP，因此采用bubinga的配置作为模板进行修改 但是bd_t传参的问题始终未能解决，我发现此结构体的定义，在uboot中和linux内核代码中根本不一致，导致传参后无法正常解析各个参数。 对于此问题，我尝试的解决方法包括： 1、更换版本，换uboot版本、内核版本，但是换过好些版本依然有bd_t定义不一致的问题 2、内核启动部分，对bd_t各项内容不采用uboot传递的数值，而是进行硬编码的赋值。这样做是可以正常启动，但是这么改也太扯了吧 这问题早就有，一直解决不了，怨念啊！希望你能指点一二，帮小弟解了这个疑惑吧 【 在 ssailing (sailing) 的大作中提到: 】 : 内核移植时 本身是可以配置启动参数的 这样参数就固定了 不灵活 : 但是通常情况下并不这样做 而是通过uboot来传递启动参数 : 另外还有很多参数是通过bd info这样的结构体来传递的 : ...................