翻译了高通相关文档部分内容,结合sm4350平台项目做的总结:
The system on chip (SoC) consists of a main APSS processor and additional processors that run on their own software. For example, on QTI SoCs, other processors that need separate software include modem, LPASS, Venus, WCNSS, GPU, and sensor low power island (SLPI). Not all these subsystems are present on all SoCs.
片上系统(SoC)由一个主APSS(Applications processor subsystem应用处理器子系统)处理器和运行自有软件的多个附加处理器组成。
例如在高通SoC上,附加处理器运行的软件包括modem,LPASS,Venus,WCNSS, GPU和SLPI. 并非所有Soc都包括这些子系统。
【modem】通信基带
【LPASS】Low power audio subsystem 低功耗音频子系统
【Venus】高通的图像处理模块
【WCNSS】Wireless Connect subsystem无线连接子系统
【SLPI】 sensor low power island 低功耗岛传感器子系统
The Peripheral Image Loader (PIL) is a framework that allows services to load and reload firmware images for each subsystem of the chipset into DDR memory.
Upon loading, TrustZone’s services are invoked to authenticate the content of the image file using a hash segment.
Once the image is authenticated, the processor of that subsystem is taken out of reset, i.e., allowed to execute instructions.
外围镜像加载(PIL)是一个框架,它允许服务将芯片的各个子系统加载或者重载到DDR内存中。
加载镜像时tz的服务会被调用,使用一个哈希段对镜像文件的内容进行校验。
校验通过后,相应子系统的处理器会解除复位,开始执行指令。
Firmware images are written in ELF (Executable and Linkable Format), which consists of a metadata portion and a program portion.
The program portion is further split up into multiple files. This splitting is done for several reasons:
1. If authentication information is found to be invalid, we do not need to load the entire image.
2. It is advantageous in low memory conditions since the amount of memory used at any given instance, when loading one segment at a time, is smaller than loading the whole image as one file.
3. Allows more flexibility for future changes to the loading procedure. The firmware image filenames all begin with a base name that matches the name of the peripheral, e.g., “modem”.
固件镜像是ELF格式(可执行可链接格式),包含数据部分和程序部分
程序部分进一步拆分为多个文件,拆分原因是:
1,如果发现校验信息无效,则不需要加载整个镜像
2,在低内存条件下更有利,因为当大量内存被已有实例占用时,每次加载一小段比加载整个镜像文件占用更小内存
3,为将来加载流程变化时提供更大的灵活性,镜像文件名字前缀和外围设备匹配,例如"modem.b**"运行在modem处理器上
The metadata file has an extension of .mdt . This comprises the ELF header, program headers, hash, and signature.
The program segment files are named with numbered extensions in the form of .bXX, where XX is the index of the sengment beginning from 00, i.e., .b01, .b02, .b03, etc. Each of these files is referred to as a segment or a “blob”.Firmware files are expected to be placed under /etc/firmware. The PIL loads each segment of the ELF image from the firmware directory using generaic kernel method request_firmware().
This places the segment into the relevant memory hole. Once loaded, TrustZone is invoked to authenticate the segment. After all the firmware segments have been successfully loaded and authenticated, PIL resets the subsystem and initiate its boot sequence.
数据文件的后缀是mdt,包括ELF头,程序头,哈希和签名。
程序文件后缀类似b00,b01等,每个文件被称作一个段或者"blob"。
固件一般放在/etc/firmware目录,PIL驱动会用通用的内核方法request_firmware()从相应目录加载。
这样可以把各个段加载到相应的内存保留区域,一旦加载,tz会对其进行校验。当所有固件段都被成功加载且校验通过后,PIL会对子系统复位并初始化启动序列。
PIL is implemented as a kernel driver at the following location: /drivers/soc/qcom/peripheral-loader.c
Generic PIL drivers: /drivers/soc/qcom/subsys-pil-tz.c
Drivers implement power up, shutdown, error handling, and RAM dump of the subsystem. Interfaces are encapsulated and registered to the SSR driver.
PIL被实现为一个内核中的驱动,位置在
通用的PIL驱动是:
该驱动实现了子系统的power up, shutdown,err handing和RAM dump功能。接口被封装并注册到 SSR 驱动程序。
(SSR subsystem restart子系统重启)
PS: 在kernel/msm-5.4/drivers/remoteproc/qcom_q6v5_mss.c中会调用request_firmware()对modem.bxx进行加载
Device tree configurations
Device tree configs for subsystems are at the following locations:
■ /arch/arm64/boot/dts/qcom/.dtsi
子系统的设备树配置位于:
PS: 在该dtsi文件中可以看到相应的compatible = "qcom,pil-tz-generic"的节点
3,文件系统相关
以sm4350为例,从sysfs文件系统中可以看到一共有6个子系统:
/sys/bus/msm_subsys/devices:
subsys0 -> ../../../devices/platform/soc/a400000.qcom,lpass/subsys0
subsys1 -> ../../../devices/platform/soc/b000000.qcom,turing/subsys1
subsys2 -> ../../../devices/platform/soc/6000000.qcom,mss/subsys2
subsys3 -> ../../../devices/platform/soc/soc:qcom,ipa_fws/subsys3
subsys4 -> ../../../devices/platform/soc/soc:qcom,kgsl-hyp/subsys4
subsys5 -> ../../../devices/platform/soc/5ab0000.qcom,venus/subsys5
从上到下分别是:adsp, cdsp, modem, ipa_fws, a615_zap, venus
除了ipa_fws外以上各个子系统的镜像除编译出来后会被common/build/build.py脚本打包为NON-HLOS.bin
刷机时用fastboot flash modem NON-HLOS.bin命令将其刷入到modem分区。
最终分别被挂载到vendor/firmware及vendor/firmware_mnt目录:
vendor/firmware/a615_zap.b00~b02 a615_zap.elf a615_zap.mdt
vendor/firmware/ipa_fws.b00~b04 ipa_fws.elf ipa_fws.mdt
Vendor/firmware_mnt/image/modem.b00~b34 modem.mdt
Vendor/firmware_mnt/image/adsp.b00~38 adsp.mdt
Vendor/firmware_mnt/image/cdsp.b00~-11 cdsp.mdt
Vendor/firmware_mnt/image/venus.b00~-19 venus.mdt
4,其他常用mbn文件
高通平台除了以上子系统相关镜像外,还有一些常用的mbn文件:
1,bdwlan.bin, bdwlannu.bin是wifi的bdf(board data file)文件 , 由射频同事使用QSPR综测校准工具生成后提供给软件
软件将其合入vendor/qcom/nonhlos/WLAN.HL.3.3.2相应目录,编译时打包到super镜像
运行时由kernel/msm-5.4/drivers/net/wireless/cnss2驱动进行加载。
2, wlanmdsp.mbn是wifi的固件,打包在non-hlos.bin中,由modem的elf_loader加载后运行在基带处理器上
3,devcfg.mbn允许OEM修改qup(Qualcomm Universal Peripheral高通统一外设)配置,例如将一个qup由i2c配为spi
4,tz.mbn是高通二进制提供的trustzone的镜像
5,rpm.mbn Resource Power Manager电源管理模块,运行在独立的rpm处理器上
devcfg,tz,rpm均是在xbl阶段加载到内存的,在FW_FLASH.CFG中可以看到
6, 指纹ta是运行在TZ中的application,由指纹厂家提供算法库及编译脚本编译为mbn,由指纹ca通过接口QSEECom_start_app()拉起来
原文链接:https://blog.csdn.net/windofchange_/article/details/121252181