本文档主要是 U-boot 下 SD 卡/U 盘自动升级功能的需求、应用场景分析及其升级原理等。并详细描述了 U-boot 下 SD 卡/U 盘升级功能的设计思路和实现细节,为后续工作相关功能开发提供参考。 说明 本文未做特殊说明,hi3516D 与 Hi3516A 完全一致 本文未做特殊说明,hi3520DV300 与 hi3521A,hi3518EV201、Hi3516CV200 与Hi3518EV200、hi3519V100、Hi3519V101 与 Hi3516AV200 完全一致 产品版本
产品版本
产品版本1
需求分析
以前的升级方案是客户通过上层应用实现,该方案可靠性差、灵活性不高,我们现在提供一种更加可靠灵活的升级方案。
在产品应用中经常有升级 Uboot、kernel 和 rootfs 的需要,只需按照以下步骤就可完成升级。
步骤 1. 将提供的镜像文件拷贝到自备的 SD 卡或 U 盘。
步骤 2. 插上 SD 卡或 U 盘。
步骤 3. 重启设备。
步骤 4. 等待升级完成。
编译开关
自动升级的编译开关在芯片配置文件中,用户可根据需要打开相应的宏定义开关。
配置文件路径
include/configs/hi3516c.h 【hi3516c】
− include/configs/hi3518a.h 【hi3518a】
− include/configs/hi3518c.h 【hi3518c】
− include/configs/hi3518ev200.h 【hi3518ev200】
− include/configs/hi3518ev201.h 【hi3518ev201】
− include/configs/hi3516cv200.h 【hi3516cv200】
− include/configs/ hi3520d.h 【hi3520d/hi3515a】
− include/configs/ godcare.h 【hi3520a】
− include/configs/ godarm.h 【hi3521】
− include/configs/ godnet.h 【hi3531】
− include/configs/ hi3535.h 【hi3535】
− include/configs/ hi3516a.h 和 include/configs/hi3516a_spiNAND.h 【hi3516a】
− include/configs/ Hi3536.h 和 include/configs/hi3536_spinand.h 【hi3536】
− include/configs/ hi3521a.h 【hi3521A】
− include/configs/ hi3531a.h 和 includ/configs/hi3531a_spinand.h 【hi3531A】
− include/configs/hi3519.h 和 include/configs/hi3519_nand.h 【hi3519v100】
− include/configs/hi3519v101.h 和 include/configs/hi3519v101_nand. h【hi3519v101】
− include/configs/hi3516cv300.h 【hi3516cv300】
− include/configs/hi3516ev100.h 【hi3516ev100】
− include/configs/hi3516av200.h 和 include/configs/hi3516av200_nand.
【hi3516av200】
− include/configs/hi3536c.h 【hi3536cv100】
− include/configs/hi3536dv100.h 【hi3536dv100】
Auto Update 详细设计
3.1.1 数据描述
3.1.1.1 简单数据描述
驱动部分只做了基本功能的移植,所以下面实例中所涉及的文件只包括 boot、kernel 和rootfs。
a. 在开始介绍 auto update 的实现之前需要了解 include/image.h 中的如下定义:
/*
* Image Types
*
* "Standalone Programs" are directly runnable in the environment
* provided by U-Boot; it is expected that (if they behave
* well) you can continue to work in U-Boot after return from
* the Standalone Program.
* "OS Kernel Images" are usually images of some Embedded OS which
* will take over control completely. Usually these programs
* will install their own set of exception handlers, device
* drivers, set up the MMU, etc. - this means, that you cannot
* expect to re-enter U-Boot except by resetting the CPU.
* "RAMDisk Images" are more or less just data blocks, and their
* parameters (address, size) are passed to an OS kernel that is
* being started.
* "Multi-File Images" contain several images, typically an OS
* (Linux) kernel image and one or more data images like
* RAMDisks. This construct is useful for instance when you want
* to boot over the network using BOOTP etc., where the boot
* server provides just a single image file, but you want to get
* for instance an OS kernel and a RAMDisk image.
文件下载, 请回复
|