目录
- 规划分区
- 烧写流程
-
- tftp更新并重新烧写uboot的命令序列
- tftp更新并重新烧写kernel的命令序列
- tftp更新并重新烧写rootfs的命令序列：
- 裸机烧录uboot
-
- 什么是裸机
- 烧录方法
- 烧录uboot
- 烧录过程分析
- 烧录kernel
-
- 配置开发板网络
- 烧录
- 烧录根文件系统
- 烧录完成后的步骤
规划分区
因为嵌入式系统为了简化，没有使用分区表来自动管理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'
-
set bootargs mem=32M console=ttyAMA0,115200 root=/dev/mtdblock2 rootfstype=jffs2 mtdparts=hi_sfc:1024K(boot),3072K(kernel),12288K(rootfs)
内存一部分给linux用，一部分给MPP用——海思专门处理h264编码的体系，体系里面有很多ko文件，运行本身时需要大量内存。所以不能将64M内存全部给linux内核，只要他们两个不碰到就没有问题
我们之前的分区表是完全硬编码的分区表，这样做如果需要更改分区表就需要去更改内核的源码然后重新编译，重新烧录很麻烦
解决办法是，在
bootargs
启动时使用传参去动态的建立分区表。于是存在两个分区表，一个是内核中默认的分区表，一个是mtdparts传参的分区表。
配置完后输入
save
保存，保存后reset重启
这就是正常启动的情况
也能看到内核编译的时间