海思3518E开发笔记1.5——flash分区及uboot、kernel、rootfs烧写并部署

规划分区

因为嵌入式系统为了简化，没有使用分区表来自动管理flash，所以都是事先定死的。所以在部署一个嵌入式系统前都要人为的定下一个分区

规划原则

• 每个分区要足够放镜像
• 尽量留一点扩展余地
• 满足上两个条件，其他随便搞

分区规划如下

分区名	分区大小	起始地址	截止地址
bootloader	1M	0X00000000	0x00100000 （1024*1024 bit）
kernel	3M	0X00100000	0X00400000
ootfs	12M	0X00400000	0X01000000

烧写流程

tftp更新并重新烧写uboot的命令序列

mw.b 0x82000000 ff 0x100000
（mw.b 写内存，以字节为单位操作，0x82000000 ff内存从0x82000000开始清成全ff，0x100000为清理的大小为1MB
tftp 0x82000000 u-boot-hi3518ev200.bin
从服务器（Ubuntu）下载文件（u-boot-hi3518ev200.bin）到内存0x82000000
sf probe 0
先选中spiflash ,0代表第一个，板上可能有多个flash
sf erase 0x0 0x100000
sf write 0x82000000 0x0 0x100000

tftp更新并重新烧写kernel的命令序列

mw.b 0x82000000 ff 0x300000
（mw.b 写内存，以字节为单位操作，0x82000000 ff内存从0x82000000开始清成全ff，0x300000为清理的大小为1MB
tftp 0x82000000 uImage_hi3518ev200
从服务器（Ubuntu）下载文件（uImage_hi3518ev200）到内存0x82000000
sf probe 0
先选中spiflash ,0代表第一个，板上可能有多个flash
sf erase 0x100000 0x300000
sf write 0x82000000 0x100000 0x300000

tftp更新并重新烧写rootfs的命令序列：

mw.b 0x82000000 ff 0xc00000
（mw.b 写内存，以字节为单位操作，0x82000000 ff内存从0x82000000开始清成全ff，0xa00000为清理的大小为1MB
tftp 0x82000000 rootfs_hi3518ev200_64k.jffs2
从服务器（Ubuntu）下载文件（rootfs_hi3518ev200_64k.jffs2）到内存0x82000000
sf probe 0
先选中spiflash ,0代表第一个，板上可能有多个flash
sf erase 0x400000 0xc00000
sf write 0x82000000 0x400000 0xc00000

裸机烧录uboot

什么是裸机

• 不带操作系统
• 空白机器（设备没有程序），未经烧录

烧录方法

空白机器的情况下，烧录方法如下

• 通过外部烧录器去烧录板载flash
• 通过主芯片提供的isp下载的机制来间接烧录板载flash

外部烧录器直接和SPI Flash交互，和芯片没有关系。
以前的做法是，SPIFLASH先单独通过烧录器和支架来烧录好镜像再把烧录过镜像的SPIFLASH焊接到板子上；不小心把uboot玩坏了，返厂是把SPIFLASH焊下来再重烧。非常麻烦

现在很多烧录器可以直接在板子上直接烧了

原理就是通过串口实现pc与3518的通信，3518再和spi flash通信
但是要求3518内部提供ISP的代码，就是我们常说的BL0

程序复位后先开始运行BL0，再通过BL0选择从哪里启动，从目标位置读取镜像进行启动

3518E的设计是从Uart启动，就相当于BL0先启动，ISP是第一选择，上电后试图从uart接收数据。
此间必然有一些协议，比如3518通过串口不断向PC发送数据，PC端有一个PC Tool进行配合，如210是DNW，海思是HI tool

PC上的工具会接受目标芯片不断发送的信息，并且按协议回复。比如芯片给pc发0x23，pc给芯片回0x87。3518收到了0x87后就知道，有一台pc准备给我ISP。

由此就对接上了，然后PC将准备好的uboot.bin发送给3518，3518再通过SPI给Flash

烧录uboot

HITool是基于eclipse java的，于是需要安装jre
然后使用HITool进行uboot的烧写

烧录开始
烧录完毕会有提示

烧录过程分析

boot download completed
这一步就是将uboot.bin传到3518中
system startup
说明uboot已经启动

Boot Started successfully!
说明bootloader启动已经成功

接下来就是一些预设的，3518和pc的串口交互信息

sf就是spi flash的简称

Send command: sf probe 0 16384 KiB hi_fmc at 0:0 is now current device [EOT](OK)
说明定位到了spi flash

接下来就是擦除flash相应的分区，从0x开始，长度为0x10 0000(1M = 1024 x 1024 bit)

最后把uboot 烧写进去
0x81000000是uboot.bin存放的源地址

接上串口，确认烧录成功

烧录kernel

• 1、将kernel从pc传入3518的SD Ram中
• 2、擦除SPI Flash相应分区
• 3、将SD RAM中的kernel烧录到SPI Flash的相应分区中

由于3518ev200的ddr是内置的，所以无法看接线
于是查看芯片手册
SDRAM范围为：0x8000 0000~0x83ff ffff

只要在这个范围内找一个4.8MB的内存的地方存放kernel即可
官方文档中推荐的是从0x82000000开始

配置开发板网络

开发板通过网线连接笔记本即可同网段
我用的是台式机，所以将开发板连接至路由器

hisilicon # set ipaddr 192.168.2.10
hisilicon # set serverip 192.168.2.95

设置ip地址
然后输入save，在用print查看
然后ping自己的虚拟机

能ping通就行

烧录

接着搭建tftp服务器
接下来按照指导文档中的流程来走
由于我们是裸机烧写uboot的，于是tftp阶段直接从kernel开始烧写

烧录根文件系统

按照烧写流程，同kernel一样，通过tftp服务器进行烧写

烧录完成后的步骤

烧写完这三个部分以后，直接reset是不能启动的
因为我们环境变量的设置还是有问题的

一个系统要能够启动，有两个关键的环境变量

• bootcmd
• bootargs

正确的bootcmd和bootargs对应的设置命令：

• set bootcmd 'sf probe 0;sf read 0x82000000 0x100000 0x300000;bootm 0x82000000'
  从0x10 0000读取0x30 0000长度（即kernel的位置），到0x8200 0000。读完直接去启动内核镜像
• set bootargs mem=32M console=ttyAMA0,115200 root=/dev/mtdblock2 rootfstype=jffs2 mtdparts=hi_sfc:1024K(boot),3072K(kernel),12288K(rootfs)
  内存32M，根文件系统在第二个分区，文件系统是jffs2

内存一部分给linux用，一部分给MPP用——海思专门处理h264编码的体系，体系里面有很多ko文件，运行本身时需要大量内存。所以不能将64M内存全部给linux内核，只要他们两个不碰到就没有问题

我们之前的分区表是完全硬编码的分区表，这样做如果需要更改分区表就需要去更改内核的源码然后重新编译，重新烧录很麻烦

解决办法是，在bootargs启动时使用传参去动态的建立分区表。于是存在两个分区表，一个是内核中默认的分区表，一个是mtdparts传参的分区表。

配置完后输入save保存，保存后reset重启

这就是正常启动的情况
也能看到内核编译的时间