软件变更核对
软件数据发布到现场后,现场在调试前需根据系统发布单和软件、数据发布单来复核,确保所拿到的软件或数据正确。这一部分作为介绍了软件包的一些基本结构及基础知识,也指导开展软件烧录相关准备工作。本节以QNX
的STR
为例,Linux
的STR
除少量文件(例如Boot
目录下的BSP
相关文件)不同外,区别不大,原理相同。
软件数据完整性核对原理及工具
确保软件、数据完整正确的方式,是核对文件特征码,一般采用对比文件的哈希值
(Hash
)的方式。文件的哈希值
,就能通过特定的算法,从一段数据中生成的一段固定长度较小的二进制值。一段特定的数据,相同哈希算法
计算出来的哈希值
是固定不变的,当该段数据发生任何改变(不管是一个字符,还是一位),所算出来的哈希值
将会不同,并且很难从哈希值
反推演算出原始数据。理论上虽有不同数据段产生相同哈希值
的可能(称为碰撞
),哈希算法
能确保这种概率极低,完全可以忽略这种情况。目前有多种哈希算法
,对于安全性要求较高的加密和数据签名等会使用最新发明的各种哈希算法
,对于一般文件完整性检查等,用得最为广泛的是仍是传统的MD5
和SHA1
:
- Message Digest Algorithm(消息摘要算法),其中我们常用第五版
MD5
来校核数据的完整性; - Secure Hash Algorithm(安全哈希算法),有
SHA1
、MD5
,SHA1
,SHA128
,SHA256
,SHA512
等,都可来校核数据的完整性。
在获取程序数据后,可使用相应的工具程序来产生MD5或SHA1值,为保证所使用的软件和数据的完整性和正确性,现场调试团队所使用的软件、数据需从调试经理处获取,不能直接去仓库获取。为防止不同版本混淆,调试经理在下载软件或数据并压缩打包后,建议使用简洁明确的命名方式;在从调试经理处得到软件、数据后,现场调试人员需再次核对确认,文件所生成的哈希值与软件或数据发布单中所标注的一致,若不一致,则表示存在错误、被修改或损坏。
哈希值
计算软件比较通用,可根据自已的习惯选用,例如Quick Hash
就是一个功能比较实用的开源软件,目前支持的哈希算法
有MD5
, SHA1
, SHA256
, SHA512
。
若在Windows
平台仅使用MD5
计算和校核功能,WinMD5Free是另一个不错的选择,使用较为简单。
软件发布的目录结构
软件发布时,提供了一些包含版本后缀的压缩包,例如
1-CC-V_SW_10.2.14.zip
2-CC-NV_SW_10.2.13.zip
WS_LC_920.zip
WS_ZC_10211.zip
以上分别对应CC的ATP软件、CC的ATO软件、LC软件和ZC软件。
当软件初发布至现场,调试人员需注意核对版本后缀(本文后版本后缀均为示例,具体项可能不同),然后在各个压缩包的各目录中存在一个文本文件保存有该目录下的各文件的哈希值。
ATP软件
1-CC-V_SW_10.2.14.zip
解压缩后,其目录结构如1-CC-V_SW_10.2.14 ├─CC-V-ATP 10.2.14 │ ├─CC-ATP_ASW │ │ ├─ATP_ASW_10.2.14 │ │ │ ├─Prog_FTP │ │ │ │ ├─No_Split │ │ │ │ │ exe.F800 │ │ │ │ │ md5_FTP_CHK_V10.2.14.txt │ │ │ │ │ │ │ │ │ └─Split_512k │ │ │ └─Prog_probe │ │ │ CC-ATP_ASW_V10.2.14 │ │ │ md5_Probe_CHK_V10.2.14.txt │ │ │ │ │ └─CC-ATP_ASW-HOST_10.2.14 │ │ └─... │ └─CC_ATP_OMAP_DB │ └─... └─CC-V-ES 10.2.5 └─...
其中,
exe.F800
是使用cp
或winscp
传入操作系统/dev/vital
设备进行烧录的方法所使用的文件(参见后续章节),而使用ColdFire
烧录时,把类似CC-ATP_ASW_V10.2.14
的文件重命名增加后缀.elf
后选择使用(参见后续章节)。在ATP软件对应的文件目录中,存在MD5信息的文本文件,我们用来核对文件的完整性。
ATO软件
2-CC-NV_SW_10.2.13.zip
解压缩后,其目录结构如下,2-CC-NV_SW_10.2.13 ├─CC-NV-ATO 10.2.13 │ ├─CC-ATO_ASW │ │ ATO.exe │ │ org_mpc_tsk_ato MD5 checksum.txt │ │ org_mpc_tsk_ato.elf │ │ │ └─CC-ATO_OMAP_DB │ └─... ├─CC-NV-ES 10.2.7 │ └─... └─CC-NV-MNT 10.2.5 ├─CC-MNT_ASW │ MNT.exe │ org_mpc_tsk_mnt MD5 checksum.txt │ org_mpc_tsk_mnt.elf │ └─CC-MNT_OMAP_DB
其中,
org_mpc_tsk_ato.elf
是ATO
软件,org_mpc_tsk_mnt.elf
则是为OMAP及MSS维护工具提供信息的软件。同样,在其目录下有相应的确MD5
值信息的文本文档,用来核对程序的完整性。ZC软件
ZC
的软件WS_ZC_10211.zip
展开后,目录结构则如下WS_ZC_10211 ├─OMAP_UEVOL_ZC_10211 ├─TK_ZC_ASW_10211 │ KRN_UEVOL_v2.0_A.s3 │ sml4ilk_128MB_Settings.reg │ TDM_UEVOL_v2.0_A.s3 │ zc_application_A.txt │ zc_application_B.txt │ zc_application_C.txt │ zc_v10211_A.s3 │ zc_v10211_A.sha │ zc_v10211_B.s3 │ zc_v10211_B.sha │ zc_v10211_C.s3 │ zc_v10211_C.sha │ ├─ZC_host_windows_non_sync_10211 └─ZC_host_windows_sync_10211
所需软件在子目录
TK_ZC_ASW_10211
下,以扩展名.s3
结尾的是软件,基本文件名部分的结尾为_A
(_B
,_C
)表明了该软件是对应3oo3
平台的通道A
(B
,C
)的。这个目录中的文本文件与CC的不同,不是保存哈希值的。这里保存程序文件的是SHA1值,放在以扩展名.sha
的对应文件中,也可用来校验对应文件名的程序文件是否完整正确。在我们使用Media Card Programmer
程序(参见后续章节)来烧录USB Key
时,该程序也会再次通过些'SHA1'值来查找对应的程序,相当于进行了一次校验。sml4ilk_128MB_Settings.reg
则是在Windows下烧录USB Key
时导入注册表对该类USB Key
的一些参数配置,供烧录程序使用。注意:因三个通道的程序采用不同算法编写,必须对应使用,一般
A
通道的软件比其它通道的软件文件数多。LC软件
LC的软件
WS_LC_920.zip
解压缩后,目录结构除名称不同外,基本上与ZC的相同。WS_LC_920 ├─LC_host_unix_920 ├─LC_host_windows_920 ├─OMAP_DB_LC_703 └─TK_LC_ASW_920 KRN_UEVOL_v2.0_A.s3 lc_application_A.txt lc_application_B.txt lc_application_C.txt lc_v920_A.s3 lc_v920_A.sha lc_v920_B.s3 lc_v920_B.sha lc_v920_C.s3 lc_v920_C.sha sml4ilk_128MB_Settings.reg TDM_UEVOL_v2.0_A.s3
数据发布的目录结构
Result
├─App Conf
│ │ App Conf.rar
│ │
│ └─intermediate data
├─Beacon layout
├─LEU
│ └─...
└─UNIVIC Conf
UNIVIC Conf.rar
数据发布结构与软件不同,一般把各组件压缩成一个文件,放置在发布目录,其中
App Conf.rar
是CC
及ZC
/LC
的软件数据UNIVIC Conf.rar
则是STR
、Opera
及应用层的配置
我们在系统发布单指定对应的数据发布单中,例如A511007_KMLF_CASCO_7117_ATC data Delivery Sheet For Onsite.pdf
,在ATC数据发布配置一章,可看到如图所示:
其中的App Conf 1.8.0
最后一栏Checksum
后的一串十六进制数据,既是App Conf.rar
的MD5
值,UNIVIC Conf 4.10.0
的Checksum
后的一串十六进制数据,则是UNIVIC Conf.rar
的MD5
值。用这些MD5
值来对应检查相应数据包的完整和正确性。
App Conf
的结构在解压缩
App Conf 1.8.0.rar
后,其目录结构如下App Conf_V1.8.0 │ CheckSum.md5 │ ├─+2 Data SGD & VES to be used │ └─... ├─+3 ZC │ └─... └─+4 LC └─...
其中
CheckSum.md5
,是保存有整个目录树的所有文件的MD5
值列表的文本文件,可以用来配合WinMD5Free
来对整个目录树的文件进行MD5
比较校核,查看文件是否与CheckSum.md5
中列表的一致。+2 Data SGD & VES to be used
中的是CC
使用的ATP
和ATO
数据+3 ZC
中的是各个ZC
的数据+4 LC
中的是LC
的数据
ATP
和ATO
数据目录结构如下
2 Data SGD & VES to be used └─2 = VES&NVES_V35.1 conf.F880 NVES O1-SpecificFields.xml O8-SpecificFields.xml SpecificEnumerates.xml Train_type_1.NVES Train_type_1.VES Train_type_nvs.txt Train_type_nvs_L2.txt VES ves.s19
这里的
conf.F880
和ves.s19
是ATP的数据,与ATP软件类似,使用cp
或winscp
传入操作系统/dev/vital
设备进行烧录的方法所使用conf.F880
文件(参见后续章节),而使用ColdFire
烧录时使用ves.s19
(参见后续章节)。NVES
则是ATO
的数据。其它文件现场不需使用。ZC
/LC
数据ZC
和LC
的结构相似,一般一条线只有一个LC
,可有多个ZC
。现以ZC
为例3 ZC └─ZC_v35 └─s3 ├─ZC1 │ cfg_result.log │ ZC_201_appli_v35_A.s3 │ ZC_201_appli_v35_B.s3 │ ZC_201_appli_v35_C.s3 │ ZC_201_database_v35.sha │ ZC_201_fsfb2_v35_A.s3 │ ZC_201_fsfb2_v35_B.s3 │ ZC_201_fsfb2_v35_C.s3 │ ZC_201_krn_v35_A.s3 │ ZC_201_krn_v35_B.s3 │ ZC_201_krn_v35_C.s3 │ ZC_201_peer_v35_A.s3 │ ZC_201_peer_v35_B.s3 │ ZC_201_peer_v35_C.s3 │ ZC_201_uevol_v35_A.s3 │ ZC_201_uevol_v35_B.s3 │ ZC_201_uevol_v35_C.s3 │ ├─ZC2 ├─ZC3 └─ZC4
目录名称中有该数据版本号为后缀,这里是
v35
,数据同ZC
软件,扩展名为.s3
的是具体的数据,为.sha
的是SHA1
值表,基本文件名有版本和通道号做为后缀(可参考前面ZC
软件部分描述)。Univic Conf
的结构Univic Conf
是整个Univic系统的支撑或配置,包括从操作系统到Opera
平台和应用层的各个组件。目录结构具体如下:UNIVIC Conf_V4.10.0 ├─Config_V4.10.0 │ ├─Boot │ │ bootLoaderMen.pmm │ │ imageMen.F004 │ ├─SingleGTW │ │ └─disk │ │ ├─dev │ │ │ └─ppu │ │ │ ppu0_iccd1.F024 │ │ │ ppu0_iccd2.F025 │ │ │ ppu0_iccd3.F026 │ │ │ ppu1_bin.F004 │ │ │ ppu1_conf.F027 │ │ │ ppu2_bin.F004 │ │ │ ppu2_conf.F027 │ │ │ ppu3_bin.F004 │ │ │ ppu3_conf.F027 │ │ ├─etc │ │ ├─project │ │ └─usr │ ├─tgt_mpc │ │ └─disk │ │ ├─dev │ │ │ └─vital │ │ │ conf.F880 │ │ │ exe.F800 │ │ ├─etc │ │ │ ip_maint.sh │ │ │ ... │ │ ├─project │ │ │ ├─bin │ │ │ │ NVES │ │ │ │ org_mpc_tsk_ato.elf │ │ │ │ org_mpc_tsk_mnt.elf │ │ │ └─conf │ │ └─usr │ │ ├─bin │ │ ├─lib │ │ ├─opera │ │ │ ├─bin │ │ │ ├─conf │ │ │ └─lib │ │ └─web │ ├─tgt_dmi │ ├─Patch_Single_core_viom │ ├─_data_generated │ └─_ip_maint_cab2 │ ip_maint.sh ├─DMI_v20 │ KMLF_V20.PCC ...
上图中,
KMLF_V20.PCC
是DMI烧录所需使用的整个系统镜像文件,bootLoaderMen.pmm
则是在烧录GTW
、CMP
等板卡的BootLoader
,而imageMen.F004
则是QNX
操作系统镜像文件,GTW
板卡需烧录Opera
及板卡配置的文件对应的目录SingleGTW/disk/
中除dev
目录外的所有内容(至不包含这个目录的原因,请参考操作系统章节),CMP
需烧录Opera
及板卡配置使用对应于tgt_mpc/disk
中除dev
目录外的所有内容,tgt_dmi
则是烧录DMI
使用的(在191基线中没见使用介绍,不知是何原因)。其中,位于
SingleGTW/disk/dev/ppu/
下的,是烧录PPU
所需的相关文件:以.F004
和.F027
分别是PPU
的软件和配置,而.F024
、.F025
和.F026
则是烧录至FPGA
的文件。位于
tgt_mpc/disk/dev/vital/
的exe.F800
和conf.F880
,则是为方便而把该数据发布版对应的ATP
软件和数据拷贝放置于此,主要用来采取cp
或winscp
传入操作系统/dev/vital
设备进行烧录的方式所使用。位于
tgt_mpc/disk/etc/
下的ip_maint.sh
,是配置CMP
面板维护网口地址的配置文件,默认放置的是列车车头(相对参考端)CMP
的IP配置,若是烧录列车尾端(相对参考端)的CMP,则需从_ip_maint_cab2
拷来替换此文件。位于
tgt_mpc/disk/project/bin/
下的org_mpc_tsk_ato.elf
和NVES
,分别是ATO
的软件和数据,在烧录时对应替换文件即可。
软件和数据变更核对
由于发布的软件和数据的App Config
部分,供烧录使用的文件数量较少,一方面通过核对软件包或包内文件名版本后缀来检查确认,另外一方面直接比较发布单中的这些包的哈希值,就能确认完整性,能较容易判定变更范围。数据发布包中Univic Conf
部分,包含了从系统的BootLoader
,到操作系统、Opera
平台、应用配置等很多部分,文件较多,不能单从整个包的版本变化来确定变更范围,具体变更范围的确定则要相对困难。下面主要描述如何核对确定这部分在数据发布后的变更范围,也就是升级范围。
在Univic Config
部分版本变化后,为确认新、旧版本间具体的变化内容,我们需准备当前装备配置版本,和升级目标版本,把这两个软件包分别解压缩后,利用目录文件比较工具来进行比较,根据比较结果来确定变更(升级)所受影响的文件列表。
能胜任目录比较工作的常用的比较工具除有著名的UltraCompare
、Compare It!
、Beyond Compare
等外,也有开源的WinMerge
等。这里介绍WinMerge,安装后可选择比较两个目录的所有文件
根据对比结果,我们可以知道那些文件不同,从而能准确判定变更范围。