PXA3xx Boot ROM Reference Manual - Marvell

PXA3xx Processor and Tavor ProcessorBoot ROM Reference Manualb) The Device Keying Binary runs on the system and must perform all of the requirementsdocumented in Section 4.1.1.1.c) The non-trusted image module, OEM boot module, and associated OS images created inStep 3 are downloaded by the Device Keying Binary using the download tool available in theMarvell ® Wireless Trusted Platform Tool Package or a custom tool created by the OEM.d) The Device Keying Binary must have the built-in capabilities to allow debug and testing of thenon-trusted image module, OEM boot module, and associated OS images created in Step 34. As a last step, the non-trusted boot operation should be verified from a power-on reset.The non-trusted boot process occurs on the platform upon every reset of an initialized platform. Thenon-trusted boot processes use the information stored in the non-trusted image module to load theimages from flash memory before transferring control, if required.4.1.1.1 Device Keying Binary Requirements for an UnprogrammedNon-Trusted SystemThe Device Keying Binary is responsible for provisioning and preparing an uninitialized system forinitial boot. It must determine the flash used to boot, program the proper images to the flash, and ifthe platform is a NAND platform, validate or create the relocation table. In addition, an OEM maywant to create multiple versions of the Device Keying Binary, one for use in manufacturing and onefor use in development. The development Device Keying Binary could be used to aid in platformdebugging.Marvell provides the Marvell ® Wireless Trusted Platform Tool Package as an example for OEMs.This package contains all of the host tools and middleware required for both trusted and traditionalboot. Contact your local Marvell field application engineer for more information.The Device Keying Binary is responsible for completing the following on non-trusted boot platforms:• Provide an interface through the UART or USB port to print messages and download binaryimages.• Set up the DDR memory and all necessary flashes to store the downloaded images. At aminimum, this would include the OEM boot module.• Create the initial bad-block table, if the flash signature in the Non-Trusted Image Moduleindicates a setup for NAND.• Perform a checksum on the images against the values stored in the non-trusted image moduleto validate a correct download.4.2 Trusted ProvisioningThe first step towards provisioning a trusted system is to review the usage cases in Section 9.1,“Trusted Boot Usage Cases” and determine the requirements. When doing so, consider thefollowing:1. How the flash device is programmed. Several options are available:a) A separate software image that is downloaded over one of the available ports.b) A system that is preprogrammed by a flash programming vendor.2. The flash device that is used for booting the system. The options are:a) X16 NAND device on data flash controller Chip Select 0.b) X8 NAND device on data flash controller Chip Select 0.c) XIP device on the static memory controller Chip Select 2.3. The Device Keying Binary that is used. Marvell provides a sample Device Keying Binary thatperforms all of the necessary tasks required to provision a trusted system. If system-leveldebug is also required, modification of the Device Keying Binary may be necessary or a newDevice Keying Binary can be developed by the OEM.12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758Doc. No. MV-S301208-00 Rev. - PUBLIC RELEASE Copyright © 2010 MarvellPage 28