linux平台针对tilepro36的BCM56334 SDK移植

转载地址：http://blog.chinaunix.net/uid-12163495-id-1988739.html

移植三部曲

编译BroadCom的SDK
芯片：交换芯片BCM56334，PHY5464，PHY5461
交叉编译OS为Tilepro
SDK版本：sdk-all-5.6.6

BCM针对其出品的所有交换芯片和PHY芯片的配置源代码都在BCM的SDK软件包中，通过编译SDK可以生成针对你所需要的芯片的内核模块映像（.ko文件），加载到OS中即可自动完成配置。

编译步骤：
（1）解压SDK包，定义并导出以源码根目录的环境变量SDK
在这之前知晓tilepro MDE中linuxOS源代码的目录:$(TILERA_ROOT)/src/sys/linux
tilepro MDE中交叉编译器使用的头文件目录：$(TILERA_ROOT)/usr/lib/tile-gcc/include
tilepro linux编译内核时生成的编译环境目录（即运行tile-prepare脚本的目录）：$(COMPILE_DIR)
（2）$(SDK)/system/linux/kernel/路径下，新建的我们自己平台目录myplat,拷贝近似平台的Makefile文件到$(SDK)/system/linux/kernel/myplat，修改平台参数和编译环境参数；
（3）在$(SDK)/make路径下，拷贝近似平台的Makefile.linux-xxx-2_6文件到Makefile.linux-myplat-2_6。
修改的主要参数有：
1）$(KERNDIR)= $(COMPILE_DIR)若指定为源文件目录(TILERA_ROOT)/src/sys/linux则找不到生成模块文件时需要的autoconf.h等文件；
2）在KFLAG参数中剔除本交叉编译器不支持的编译选项，并添加源文件的头文件路径和编译环境头文件路径
-I$(TILERA_ROOT)/src/sys/linux/include和 -I$(COMPILE_DIR)/include.
最重要的是要指定出交叉编译器运行时需要的头文件路径-isystem $TILERA_ROOT)/usr/lib/tile-gcc/include，此处如果是构建非交叉编译的映像则要指定-isystem为如/usr/lib/gcc/4.1.1/include类似的路径.
还有就是如果编译过程中出现某些Makefile中定义的宏参数未在源码中定义，则可以在该处
通过-D'macro=xxx'的形式定义。如-D'KBUILD_MODNAME=xxx'，定义了驱动名称的宏。
（4）在$(SDK)/make目录下，拷贝Make.local.templete到新文件Make.local,编辑Make.local文件选择需要支持的芯片类型和各种功能选项（不修改则默认为所有芯片都支持）
（5）进入$(SDK)/system/linux/kernel/myplat目录下运行make，启动编译过程。
（6）最后在$(SDK)/system/linux/kernel/myplat目录下生成所有的.ko文件，一般只需要自检过程需要的bcm文件和调用BCM API使用的core文件。

注意：Makefile.linux-kernel文件中的语句ORIGIN= Broadcom后面有一个空格，否则编译选项将不同，编译会带来麻烦。

BCM56334 SDK针对tilepro36的移植

SDK版本：sdk-all-5.6.6

操作系统版本：tile-linux 2.6.26

该工作没有什么现成的文档进行参考，主要还是在实际的SDK移植工作中进行经验积累，认真阅读SDK源代码，从中获得一些Broadcom文档中没有提到过的软件流程和操作。

一.移植过程中sdk源代码主要修改的地方有：

1. 将system/bde/linux/kernel/linux-kernel-bde.c文件中无法解析的系统导出符号如virt_to_bus和bus_to_virt用tile-linux系统代码替换,因为我们选择的硬件体系make文件来自与raptor体系，所有需要注销掉raptor体系中使用的MIPSCPU相关的系统定义参数如

2. 将sdk中所有与pciebar内存空间（主要是base_address相关的地址）的读写操作替换为tilelinux要求的tile_readl和tile_wirtel函数接口，因为tilepro36最pcie内存空间读写不允许直接对内存地址进行读写（通过指针的方式）。

其他没有修改的地方，可见broadcom的sdk软件对系统移植所作的工作非常成功，极大的方便了用户的移植，缺点只是提供的文档不够充分，要求能够从源代码中快速定位并解决问题。

二.加载BCM shell

该过程中出现了小小的插曲，刚开始时进行了一中的工作后，发现每次加载bcm.user.proxy程序后都会出现反复打印参数无法解析的错误信息直到死机，或者是进行shell了但ps查看端口状态出现死机的现象。听取总工的意见使用一个tile核运行tile-linux,防止由于SMP的原因造成模块死机，修改后BCM shell运行稳定，或许是由于sdk中的SMP及锁机制与特殊的tile-linux不符造成的，原因待查。但每次上电硬件重启后首次加载bcm模块还会出现反复打印参数无法解析的错误，但带电手动复位或中断加载过程重新加载模块则模块运行正常。总之，单核运行后，ps能正确显示link
up的链路端口，以及查看各端口收发数据报数量，操作MII对phy寄存器进行读写。

补充：关于bcm-shell不能在开启多个tile时执行问题的解决。

开启多个tile时，每次启动时都发现linux-kernel-bde.c文件_dma_segment_alloc函数中，执行语句MEM_MAP_RESERVE(VIRT_TO_PAGE(page_addr));时出现系统crash，简单的注销掉即可屏蔽问题。

三.调试链路

mpcb使用bcm5461与tile的gbe0接口连接，协议是SerDes(switch)->RGMII(gbe0)，phy工作在fiber模式 ；

使用bcm5464与amc子卡arm以太网接口、amc子卡fpga以太网接口以及后插卡以太网接口进行连接，协议是SGMII(switch)->1000base-T(以太网接口)，phy工作在copper模式；

5464为4个5461的集合芯片，二者功能相同，需要注意的是对0x18,0x1c等shadow register的读写操作方式，不同之处是5464的phy地址以端口0开始逐渐增1。

之前链路无法ping通一直怀疑是phy芯片没有正确的配置。但最终的结论是只要硬件管脚设置到正确的工作模式，软件不需要配置任何phy寄存器，只需要检测自协商情况下的linkup位等待链路建立。

5461遇到的情况及解决的方法是：

gbe0发送的报首先在交换芯片端口上可以查看到，甚至在外部pc机也可以通过抓报工作正确识别出，但gbe0接收到的数据包使用交叉编译后的工具tcpdump在tile上抓取，发现每次受到的数据报会有比特随机变化。

原因是由于tilepro36 gbe0端口的数据接收时钟线RXC需要对数据接收线RXD要求有时间上的延时，但5461对该延时控制可以在copper模式下通过设置寄存器做到，但在fiber模式下5461不支持该延时操作，所以只能通过硬件电路绕线的方式人工增加所需要的延时量。

5464遇到的情况及解决的方法是：

5461是通过tile的MII接口进行读写，而5464是通过交换芯片的MII接口进行读写的，通过BCM shellphy命令手动读写5464各寄存器发现配置及状态正常，只是BCMshell在扫描的时候把本来接在ge18~ge21的1个5464（但该四个端口都应该显示为5464）扫描成了ge0~ge2三个端口的三个5464，缺少了一个5464通道。

认真查看sdk代码发现源代码在进行各端口port对应的phy扫描时，内部存在一个定义好的每个port应该扫描的phy地址表格，当选择外部phy扫描时，从ge0(port2)到hg3(port29)，对应的phy地址从0x1到0x1d，所以在没有指定kconfig_list参数字符串的情况下，默认ge0端口从phy地址1查起，所以只能扫描到3个phy通道，而且还是从不正确的port2(ge0)开始的。

可以通过函数kconfig_set("port_phy_addr.port21.BCM56334_A0","0x01")语句人工指定mpcb对应端口的phy地址。

注：BCM shell中的ge0并不对应port0，因为port0和port1用于芯片内部通道使用，所有ge0为port2开始。

10G端口遇到的情况及解决方法是：

mpcb的10G端口xgbe0与交换芯片hg0端口进行直连。

现象是xgbe0能够发送数据报到交换芯片的对应端口，但在BCM shell和pc机端都无法抓取不到数据报，同时xgbe0端口也无接收到数据的信息显示。

解决方法是：

首先通过查看bcm shell保证经过交换芯片的数据报没有错误，尤其是CRC错误；

其次broadcom为了实现级联将10G传输的标准以太网报改装成私有的HiGig+或HiGig2形式，该私有以太网报无法被正常的网络协议栈设置所接收，所以会造成数据报显示错误或无法接收和抓取到数据报；

修改方法是在bcm shell中使用命令port 26encap=ieee其中port26为hg0，将默认的10GHigig端口改为标准的以太网10G接口；或者是修改多核处理器端寄存器配置以适应HiGig私有报格式。

SDK-5.9.1针对BCM56334移植后的剪裁

bcm56334_b0在sdk-all-5.9.1移植后，为了方便系统启动时自动加载以及缩小.ko文件尺寸，需要将bcm-shell,appl等部分剪裁掉，方法主要是修改各级目录的makefile文件，使其只编译生成必须的两个模块文件：

linux-kernel-bde.ko和linux-bcm-core.ko

需要修改的地方如下：

1 去掉$SDK/src/Makefile中目录搜索参数subdirs的appl，可以清除bcm-shell等应用的编译；

2 设置Make.local文件中NO_SAL_APPL＝1，可清除sal应用的编译；

3 使Make.local文件中DISPATCH_LIST宏只保留ESW,清除掉其它体系文件的编译，FEATURE_LIST也可进行删 减或设置为EMPTY；

4 开启Make.local文件中三个配置参数：

CFGFLAGS+=-DSOC_NO_NAMES

CFGFLAGS+=-DSOC_NO_ALIAS

CFGFLAGS+=-DSOC_NO_DESC

5 修改$SDK/systems/linux/kernel/common/Makefile文件中生成5个.ko模块对应的宏：

KERNEL_XXX_LOCAL和KERNEL_XXX，令不需要的模块宏为空。

同时删除编译目标all中的依赖目标user_apps和link_check。

另外只保留$SDK/systems/linux/kernel/modules/Makefile文件中subdirs参数中的子参数shared 和bcm-core。

这样可以使不需要的模块和bcm-shell不编译；

6 此外还可能需要删除并修改$SDK/systems/linux/kernel/modules/bcm-core/bcm-core-symbols.h文件中的某些没有编译的模块中的符号；

7 加载bcm-core模块时可以通过指定参数init=bcm代替在bcm-shell启动后手动输入init bcm进行初始化，此初始化需要执行bcm-core.c文件中的bcore_init_all文件，因此需要使unit参数的范围定义宏在bde与bcore两个模块文件中保持一致；

8 通过以上步骤可以将映像大小由未删减之前的30M缩减到15M，为了进一步删减映像大小，还可以将不需要的bcm-API函数删除，可能需要修改的文件如下：

$SDK/src/bcm/api_ref.c

$SDK/src/bcm/dispatch.c

$SDK/systems/linux/kernel/modules/include/bcm-export.h

$SDK/src/bcm/esw/init.c

$SDK/src/bcm/async_run.c

$SDK/src/bcm/loop.c

此外$SDK/src/soc/phy目录有许多不需要的phy文件可以删除掉；

$SDK/src/bcm/esw/下各芯片体系有许多交叉使用的文件，可以选择性删除，但不推荐这么做，因为enduro的芯片某些功能会使用同样esw下其它体系芯片的该功能文件，会造成混乱；

9 关于源代码中涉及到的芯片feature特性，源代码中定义在feature.c文件，打印出的bcm56334_b0默认feature特性参见文章bcm56334 soc-feature。所有property都为空；

另外可以参考我的资源：GenericSDK 5.6.6 Introduction.pdf

http://download.csdn.net/detail/qingfengtsing/7074025