基于QCA9531+AP143参考设计的spiflash升级扩容，w25q64升级为w25q128

硬件平台：QCA9531+AP143参考设计

目的：将spiflash由winbond  w25q64更换为w25q128(8M--->16M)

背景：由于项目更新迭代需要增加一些新的功能，原有的8Mflash容量已经不能满足现有需求，所以将flash从8m升级成16M，为后续在该平台上的开发提供基础支持

整体思路

软件：

1.由于flash在开发板刚上电的时候会被uboot进行初始化,所以要修改uboot源码中关于该板型的flash描述的的代码

2.修改原有的bootargs里有关分区的设置,把新的flash分区计划告诉内核

3.确认内核源码中的对winbond厂商的支持，以及存在这款flash的相关驱动代码，如果没有，需要手动在flash厂商网站下载驱动代码，放到源码目录下，并增加编译规则，将必要的驱动程序编译进内核

4.将以前8mflash中的固件提取出来，准备将其移动到16M里

硬件：

查看QCA9531+AP143参考设计，确认硬件平台和该flash的兼容性

考虑新flash的引脚数量，定义，序列

思路总结：

经过逐一确认上面的条目，发现由于新旧FLASH的屋里引脚数量，定义和序列完全一致，所以在硬件上，直接将旧的拆下，把新的pin-to-pin焊上去就可以，接下来全部都是软件要做的工作了

具体实施：

在uboot源码中找到include/config.h该文件，内容如图，这个.h文件被board953x.c文件包含。查看到FLASH_SIZE的定义，将其从8m改为16m

2,修改bootargs参数为如下：setenv bootargs "console=ttyS0,115200 root=/dev/mtdblock3 rootfstype=jffs2 init=/sbin/init mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),2432k(uImage),13504k(rootfs),64k(mib0),64k(ART) mem=128M"

256+64+2432+13504+64+64=

这里面重点修改了uimage和rootfs分区的大小，因为其他分区里存放的文件一般不会有太大变动，uimage的体积一般不会变动，除非修改内核配置，在内核变异的时候增加了新的功能进去才会让他的体积变大。在应用层的开发中，最重要的就是文件系统的大小，系统里存放了所有的用户数据升级flash的主要目的就是为了扩容系统大小。

按照这个分区规划，刚好16M

转成16进制地址：
0x000000000000-0x000000040000 : "u-boot"
0x000000040000-0x000000050000 : "u-boot-env"
0x000000050000-0x0000002b0000 : "uImage"
0x0000002b0000-0x000000fe0000 : "rootfs"
0x000000fe0000-0x000000ff0000 : "mib0"
0x000000ff0000-0x000001000000 : "ART"
 

3,，分区设置好之后，接下来查看内核配置,在内和源码driver/mtd/spi-nor/spi-nor.c文件里的flash_info spi_nor_ids[]结构体数组中可以看到里面有对w25q128的描述

所以可以直接在mips-linux-2.6.31/arch/mips/configs/board953x_defconfig板子的配置文件里将flash名称改为W25Q128,在编译内核的时候这个defconfig文件会拷贝到.config里，然后根据.config的配置规则去选择编译不同的.c驱动文件，举个例子，如果我们的在board953x_defconfig配置了CONFIG_NFS_FS=y,这个NFS_FS选项可以在fs/nfs/Kconfig里找到，Kconfig里的描述决定了它在makemenuconfig里的样子和属性，具体的可以看Kconfig语法

Kconfig配置界面：

makemenuconfig界面：

当我们在makemenuconfig中选中了这一项，用[*]选中，表示将他编译进内核，保存到默认配置文件或者.config文件里，退出，这时候就可以看到CONFIG_NFS_FS已经变成了=y，然后，在fs/nfs目录下的Makefile文件按中可以看到如下规则，如果CONFIG_NFS_FS=y,也就是obj-y+=nfs.o,这个意思是如果选中了这一项，那么内核在编译的时候就会生成nfs.o目标文件，再看下面nfs.o又依赖于这么多其他.o文件，所以会根据makefile规则解析并寻找所需编译的.c文件。

另外，如果需要将自己写的驱动添加到内核，或者是如果内和源码中没有对某个外设的驱动支持，可以从网上下载驱动，放到内核源码中的指定位置，然后修改kconfig，Makefile，就可以在makemenuconfig界面自由选择自己的配置，下方是我自己将网上下载的网卡驱动添加到内核源码中并编译进内核中的示例

做完了上面三步后，重新编译uboot和内核，然后用新的固件测试具体步骤如下

测试适配16Mflash的固件：

1.先用烧录器将8Mflash拷贝到16M上面，这样的目的是为了保证先让新flash能启动uboot,只有Uboot启动了，才能使用tftp从服务器下载刚制作好的新固件，因为开发板上电后要从spinorflash里读取数据，新的flash上面什么都没有，就没办法对开发板操作

拷贝完成后，将flash焊接到板子上，上电，uboot启动，点击键盘打断bootdelay倒计时，进入uboot命令行，然后通过tftp下载新的uboot

tftp 0x80060000 ${dir}u-boot.bin&&erase 0x9f000000 +$filesize&&cp.b $fileaddr 0x9f000000 $filesize

接下来重新给开发板上电，这时候他就会以新的uboot启动，结果如下：

看到了打印信息，可以看到他已经正确识别到了16Mflash，包括厂商ID,设备ID都是正确的，0xef4018,和之前flash_info spi_nor_ids[]结构体数组里对w25q128成员的描述一致。直到uboot启动完成后，并出现了staring kernel,这里就放心了，因为到这里uboot负责启动内核的使命就已经结束了，看来uboot已经没问题了，不过最终还是要等正常进入系统后，用命令查看系统的可用容量，那个才是最有说服力的。。。

好了，既然uboot已经正确识别这款flash，那么接下来我们测试新的内核uimage

用同样tftp的方式，根据分区设置，将uimage烧到指定地址，然后用bootm加载启动新的内核

在内核启动的时候，他会去解析uboot传过来的bootargs设置，由于在内核配置中选中了mtd相关功能并编译进内核，所以内核在启动时，内核的mtd子系统会根据分区规则，对flash自动去划分分区,我们将这些地址范围转化成便于理解的kb单位，发现和我之前规划的分区一致，直到内核启动完成，未发现kernel panic死机情况，可以正常进入到文件系统，这就意味着即将大功告成。

通过启动日志看到，当内核启动完成后，他去flash的第三个分区去尝试挂载文件系统，并执行init进程。由于升级flash并不涉及系统层面，所以我没有修改buildroot的配置，rootfs没有变化，还是以前的，应该不会有问题。在用telnet登陆进开发板之后，从如下结果可以看出来，已经升级成功了，现在系统可用空间为13.2M，我为rootfs分区规划的空间为13504K，/proc/mtd的分布也是正确

接下来再把最后两个分区的固件通过tftp下载到指定的位置，我也不太清楚mib0.bin和art.bin的作用，反正为了保证16Mflash里的固件内容完整，烧进去就行了...

至此，升级就完成了，暂时不用担心以后项目增加新的需求但是容量不能满足的问题了