PXA3xx Boot ROM Reference Manual - Marvell

PXA3xx Processor and Tavor ProcessorBoot ROM Reference ManualThe trusted boot process occurs on the platform upon every reset of an initialized platform. Thetrusted boot processes use the security information stored in the trusted image module and thesecurity information programmed by the Device Keying Binary to integrity check the images loadedfrom the flash before transferring control. If the validation process fails, the boot operation is halted.The validation process is a series of checks on the Marvell ® WTM and the images loaded into theflash. If the Marvell ® WTM is successfully initialized, the Boot ROM starts the validation process onthe images in the flash. Validation uses the RSA digital signature and the SHA-1 based digitalsignature verification of the trusted image module and OEM boot module in the validation process.Computed hashes are compared with hashes stored in the flash, which allows the Boot ROM todetect any changes that have occurred since the last boot attempt. If an error occurs at any point inthe process, the boot process halts.4.2.2 Device Keying ProcessThe device keying process occurs on an uninitialized platform, as defined by the Boot ROM fuses.Device keying is performed during platform manufacturing, when the platform configuration fusescan be programmed through the Marvell ® WTM. The fuses can also be programmed during themanufacturing of the processors at the Marvell factory. The OEM must use the Marvell ® WirelessTrusted Platform Tool Package to generate a trusted image module with all of the necessary securityinformation for the trusted boot process. Optionally, an OEM could develop custom tools to generatethe trusted image module according to Chapter 7, “Trusted Image Module”.1. During the device keying process, the Boot ROM listens for a download request on either theUART, differential USB, or single-ended USB port to start the download process.2. If a request has been initiated, the Boot ROM begins by downloading a trusted image module toa reserved location in the internal SRAM. This trusted image module should cover the DeviceKeying Binary that is downloaded next.3. After examining the load address for the Device Keying Binary from the trusted image module,the Boot ROM downloads the Device Keying Binary to this address and the Device KeyingBinary should have been linked to execute from this location. Depending on the setting of thesecure download enable fuse, the trusted image module and the Device Keying Binary may beintegrity checked or control is transferred to the Device Keying Binary directly.4. Once the downloaded Device Keying Binary is given control, it is responsible for completing therequirements listed in Section 4.2.2.1, “Device Keying Binary Requirements for anUnprogrammed System”. The OEM should have its own proprietary secure schemeimplemented in the downloaded OEM boot image. Execution of this scheme allows furtherdownload and future security checking of the OEM’s supplementary binaries for itsOS/application/data, as well as the mobile operator’s service provisioning modules.To allow an OEM to debug images, hooks have been provided in the Boot ROM to allow commandsto be issued. Refer to the command protocol section in Chapter 11, “Communication Protocol” fordetails about the commands. The debug commands are allowed only on an uninitialized platform.Once the platform fuses are configured, debug commands are disabled. The Device Keying Binarymust allow for the debug capabilities to be used by having an option to skip programming the fuses,which also implies that the Device Keying Binary should have a mode where it skips the download ofimages and only programs the fuses. The way this process is implemented as defined by the OEM.One suggestion is to support additional commands through the port protocol to allow for separatingthe steps of the platform provisioning.4.2.2.1 Device Keying Binary Requirements for an Unprogrammed SystemThe Device Keying Binary is responsible for provisioning and preparing an uninitialized system forinitial boot. It must determine the flash that is used to boot, program the proper images to the flash,integrity check images if required (secure download enabled), program the platform configurationfuses, program the one-time programmable registers on NOR platforms, and if the platform is aNAND platform, validate or create the relocation table. In addition, an OEM may want to create12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758Doc. No. MV-S301208-00 Rev. - PUBLIC RELEASE Copyright © 2010 MarvellPage 30