1 / 38

KeyStone Bootloader

Multicore Applications. KeyStone Bootloader. Agenda. Remote Boot Loader (RBL) Reset (Trigger) Types Boot Methods Boot Process Second Stage Bootload Option Intermediate Boot Loader (IBL). Remote Boot Loader (RBL): Purpose.

melody
Download Presentation

KeyStone Bootloader

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Multicore Applications KeyStoneBootloader

  2. Agenda Remote Boot Loader (RBL) Reset (Trigger) Types Boot Methods Boot Process Second Stage BootloadOption Intermediate Boot Loader (IBL)

  3. Remote Boot Loader (RBL): Purpose • RBL enables user to transfer application code from memory or host to high speed internal memory or DDR3. • RBL provides multiple choices to the user to boot the device. • These boot choices can be broadly divided into two groups: • Memory boot where the application code is stored in a slow external memory and DSP acts as a master and drives the boot process. • Host Boot where the DSP is configured as a slave and driven by a host device connected through fast transport.

  4. Remote Boot Loader (RBL): Definition Remote Boot Loader (RBL): • Software code used for device startup. • Burned in ROM (non-modifiable) during manufacture • Has a base address of 0x20B00000 • RBL can be executed by C66x core or the ARM core. The boot behavior varies depending onthe core type that initiates the boot process. C66x CorePac • ROM ARM CorePac

  5. Boot Requirements • Selecting the method of booting. • Updating the configuration. • Trigger to use the configuration to prepare for booting. • Load the image of the executable into the device. • Trigger the device to run the executable.

  6. Terminology (1/2) • Boot Parameter Table is a configuration table that contains two parts: • Common set of parameters for system configuration • Unique parameter settings for each boot method • Boot Table contains code that needs to be loaded into the device. • Boot Configuration Table is a register configuration table that is used to manipulate memory map register.

  7. Terminology (2/2) • Triggers are mechanisms that initiates the execution of the RBL. KeyStone devices use resets as triggers. • Four types of resets: • Power on Reset (PoR) • Reset Full • Reset • Local Reset

  8. Reset Types • Power on Reset (POR) (Cold Reboot) • Resets everything • Latches the boot strap pins • Initiates RBL process • RESETFULL (Warm Reboot) • Resets everything • Latches the boot strap pins • Initiates RBL process • RESET (Configurable as Hard Reset or Soft Reset) • Resets everything except EMU and reset-isolated peripherals • No latching of the boot strap pins • For software reset, PCIe, EMIF16, DDR3 and EMIF MMRs are also preserved. • Initiates RBL process • LRESET (Local Reset) • Mostly used by watchdog timer • Only the CorePac is reset; All memory is preserved. • Does NOT initiate RBL process

  9. Device Startup from Hard/Soft Reset • For hard resets, the boot code must determine the hibernation state. • Hibernation is the process of shutting down unused CorePacs and IP blocks to reduce overall system power consumption. • It is the responsibility of the application to save all relevant configurations and register values based on the selected hibernation mode. • Hibernation1: Values stored in MSMC SRAM. • Hibernation2: Values stored in DDR3. • The application is also responsible for setting the appropriate hibernation mode in the PWRSTATECTL register. • The Application will also set the branch address in the PWRSTATECTL register.

  10. Hibernation Explained • Hibernation 1: The application needs to ensure that the chip control register is set correctly to avoid MSMC reset. • Hibernation 2: MSMC is reinitialized to default values. • For both modes, the application is responsible for shutdown of all desired IP blocks. • A hard or soft reset can be configured to bring a hibernating device out of hibernation: • After the reset, the boot loader code checks the PWRSTATECTL register to identify the hibernation mode and branch address. • Subsequent actions: • Peripherals and CorePacs are powered on. • The awakened device branches to the application code, which utilizes the values stored in MSMC or DDR3 prior to hibernation.

  11. Setting up the Boot Configuration • A set of GPIO pins are used to provide the boot configuration; Refer to the Data Manual for your device. • The logical levels of these pins can be controlled by an external pull-up/pull down resistor or external host (FPGA/CPLD). • These pins are sampled during the power on reset and written to DEVSTAT register. • The RBL uses the values in the register to execute the boot process.

  12. RBL Flow • The RBL uses the Device Status (DEVSTAT) register and generates a configuration table (Boot Parameter Table). • The RBL uses the Boot Parameter Table to configure the device to boot. • Depending on the boot method and the trigger type, the boot image is loaded into the device. • After the complete image download into the device memory, the RBL initiates the code to execute.

  13. RBL Flow Diagram

  14. Common Boot Configuration • PLL settings • Boot method • Boot-related configuration • PCIe-Subsystem enable (PCIESSEN) • Identify master that is driving the boot

  15. Boot Methods • The available boot methods vary according to the device: • I2C boot • I2C passive mode • SPI boot • NAND boot • XIP boot [EMIF NOR boot] • UART boot • Ethernet boot • SRIO boot • HyperLink boot • PCIe boot • For more information, refer to the Data Manual for your device.

  16. PLL Configuration • The boot code sets the PLL multiplier based on the core frequency set in the EFUSE register. • The boot configuration specifies the reference clock used in the system: PLL Clock O/P = (Input Clock x (Clkf + 1))/(2 * (Clkr + 1)) • Refer to the data manual for your device to determine the exact PLL configuration.

  17. Boot Configuration Format Boot Parameter Table: • Provides a “map” for the boot process • The boot process copies a default Boot Parameter Table into a reserved L2 of Core 0. • The first 10-byte offsets of the Boot Parameter Table are common across all the boot modes: • Length • Checksum • Boot Mode • Port Num • PLL configuration (most significant bits) • PLL configuration (least significant bits) • The rest of the Boot Parameter Table is boot-mode dependent.

  18. Boot Image Format Boot Table: • Block of data that contains the code and data section • The block is loaded from the host or external memory to the internal memory or DDR by the RBL. • The first 8 bytes of the Boot Table form the header: • 32-bit section bytes count • 32 bit section address where the block has to be moved • The end of table is identified by writing 0s.

  19. Register Configuration Format Boot Configuration Table: • Provides read/modify/write capabilities to any memory on the device. • Each entry has three 32-bit-wide elements. • First element is the address to be modified • Second element is the set mask • Third element is the clear mask • If all three elements are 0s, this indicates the end of the Boot Configuration Table.

  20. Boot Process Boot Process • Depends on boot method • Broadly divided into two methods: • Direct image boot process • Boot table boot process

  21. Boot Process: Direct Image • The device will be configured as slave. • Master has the knowledge over memory map of the device. • DirectIO SRIO boot • PCIe Boot • HyperLink Boot • The RBL configures the peripheral and set the device to get the image. • The host will send the data one section at a time. • The host will also update the Boot Magic Address (BMA) • Wake the master core in the device which will triiger the core to jump to BMA and execute the image.

  22. Boot Process: Boot Table (1/2) • In this mode the image will be converted into the boot table using hex6x. • The the image is sent by the host one section at a time in case of the host boot method. • Messaging SRIO boot • Ethernet boot • UART boot • The master core running the RBL will read sections from the memory in case of mem boot • I2C boot • SPI boot • NAND boot

  23. Boot Process: Boot Table (2/2) • The RBL also reads the start address and populate the BMA • Once all the sections are loaded, the master core jumps to the address specified in BMA and start executing.

  24. XIP Boot • The XIP boot mode does not fit in either the direct image or boot table mode of booting. • After the initialization, the master core jumps to the 0x70000000 address and starts executing.

  25. I2C Boot • PLL is in bypass mode. • Can be used to run a work-around before running the main boot method • Can modify the boot parameter table that is used by RBL. • After running the work-around, can modify the boot parameter table to boot in another boot method. • Images are stored in the EEPROM in two pages that are divided into blocks of 0x80 bytes.

  26. I2C Passive Mode Passive mode • The I2C device configuration uses 5 bits of device configuration instead of the 7 bits used in master mode. • The device does not drive the clock, but simply acks data received on the specified address. • The I2C address is calculated by adding 0x19 to the I2C address specified in the device configuration. • Header format:(0x19 + I2C address) xx xxyyyyzzzzwhere: • xx xx = length • yyyy = checksum • zzzz = boot option

  27. SPI Boot • Same as I2C mode • The only difference is that instead of pages, the NOR flash isselected based on the chip select.

  28. Ethernet boot • The RBL configures the SERDES, NETCP (if available on the device), and starts transmitting the Ethernet-ready packet. • The PHY is NOT configured. • The host can use the Ethernet-ready packet to generate the image packets to transmits into the device.

  29. SRIO Boot • RBL configures the SRIO to operate both in messaging mode and DirectIOmode. • In messaging mode, the SRIO boot is similar to the Ethernet boot. • In DirectIO mode, the master core is in poll mode, polling the BMA. • Once the host loaded all the sections of the image, it should populate the BMA.

  30. PCIe Boot • RBL configures the device in Endpoint mode. • RC mode is NOT supported. • The PCIe boot process is similar to DirectIO SRIO boot. • One difference is that the master core is in idle state and the RC should wake the core by sending a legacy or MSI interrupt after loading the image and BMA.

  31. HyperLink Boot • The process is same as PCIe boot.

  32. Booting Multiple Cores • During the boot process, the boot loader code is loaded into the L2 of CorePac 0 from the ROM. • The high 0xD23F (52K) bytes of L2 in all CorePacsare reserved for the boot code. User should not overwrite this area. • All the other cores will execute an IDLE. • User should load the image into the L2 of CorePacs they want to boot. • Before setting the Boot Complete register, the user should also set the start address of the code in the respective BOOT MAGIC ADDRESS of the CorePac L2. • Finally, the user image should also write the IPC Interrupt register to bring the required CorePacsout of IDLE.

  33. Second Stage Bootload Option Remote Boot Loader (RBL) Reset (Trigger) Types Boot Methods Boot Process Second Stage BootloadOption Intermediate Boot Loader (IBL)

  34. Second Stage Boot Load Process • Q: What if more boot parameters are needed than can be specified in the boot pins? • A: Other parameter values can be updated through the I2C boot mode. • In this case, the I2C boot starts with an I2C boot parameter table which in turn loads a custom updated parameter table for a specific boot mode. • Once the default parameter table is updated, the boot code executes using the updated boot parameter structure, following the same process as the primary boot mode.

  35. Second Stage Boot Load Specifics • The loaded EEPROM image has two boot parameter table blocks. • The first block is an I2C boot parameter table, which sets the core clock and the address of the next block. • The next block includes the requested boot mode-specific boot parameter table with user-specified values. • After loading this image into the EEPROM, the boot mode in the boot strap is set for I2C master boot. • After POR, the I2C boot code is executed as a first-stage boot load, which updates the default boot parameter table and re-enters the boot code, executing the boot code utilizing the user-specific parameters.

  36. Intermediate Boot Loader (IBL) Remote Boot Loader (RBL) Reset (Trigger) Types Boot Methods Boot Process Second Stage BootloadOption Intermediate Boot Loader (IBL)

  37. Intermediate Boot Loader (IBL) • Originally created as a work-around for a PLL locking issue in the C667x PG1.0 version. • Same process as second stage boot loading. • Also provides additional boot features: • TFTP boot • NAND boot • NOR boot • In the EVM, the FPGA is programmed to boot IBL, execute the PLL fix, and then jump right back to RBL for the set boot mode.

  38. For More Information • For more information, refer to the Bootloaderfor KeyStone Devices User's Guide. • For questions regarding topics covered in this training, visit the support forums at theTI E2E Community website.

More Related