4Remote 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.
5Remote Boot Loader (RBL): Definition Software code used for device startup.Burned in ROM (non-modifiable) during manufactureHas a base address of 0x20B00000ROMC66x CorePacARM CorePacRBL can be executed by C66x core or the ARM core. The boot behavior varies depending on the core type that initiates the boot process.
6Boot 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.
7Terminology (1/2)Boot Parameter Table is a configuration table that contains two parts:Common set of parameters for system configurationUnique parameter settings for each boot methodBoot 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.
8Terminology (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 FullResetLocal Reset
10Reset Types Power on Reset (POR) (Cold Reboot) RESETFULL (Warm Reboot) Resets everythingLatches the boot strap pinsInitiates RBL processRESETFULL (Warm Reboot)RESET (Configurable as Hard Reset or Soft Reset)Resets everything except EMU and reset-isolated peripheralsNo latching of the boot strap pinsFor software reset, PCIe, EMIF16, DDR3 and EMIF MMRs are also preserved.LRESET (Local Reset)Mostly used by watchdog timerOnly the CorePac is reset; All memory is preserved.Does NOT initiate RBL process
11Device 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.
12Hibernation 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.
13Setting 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.
14RBL FlowThe 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.
18Boot Methods The available boot methods vary according to the device: I2C bootI2C passive modeSPI bootNAND bootXIP boot [EMIF NOR boot]UART bootEthernet bootSRIO bootHyperLink bootPCIe bootFor more information, refer to the Data Manual for your device.
19PLL Clock O/P = (Input Clock x (Clkf + 1))/(2 * (Clkr + 1)) PLL ConfigurationThe 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.
20Boot Configuration Format Boot Parameter Table:Provides a “map” for the boot processThe 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:LengthChecksumBoot ModePort NumPLL configuration (most significant bits)PLL configuration (least significant bits)The rest of the Boot Parameter Table is boot-mode dependent.
21Boot Image Format Boot Table: Block of data that contains the code and data sectionThe 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 count32 bit section address where the block has to be movedThe end of table is identified by writing 0s.
22Register 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 modifiedSecond element is the set maskThird element is the clear maskIf all three elements are 0s, this indicates the end of the Boot Configuration Table.
24Boot Process Boot Process Depends on boot method Broadly divided into two methods:Direct image boot processBoot table boot process
25Boot Process: Direct Image The device will be configured as slave.Master has the knowledge over memory map of the device.DirectIO SRIO bootPCIe BootHyperLink BootThe 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.
26Boot 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 bootEthernet bootUART bootThe master core running the RBL will read sections from the memory in case of mem bootI2C bootSPI bootNAND boot
27Boot Process: Boot Table (2/2) The RBL also reads the start address and populate the BMAOnce all the sections are loaded, the master core jumps to the address specified in BMA and start executing.
28XIP BootThe 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 0x address and starts executing.
29I2C Boot PLL is in bypass mode. Can be used to run a work-around before running the main boot methodCan 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.
30I2C 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 xx yy yy zz zz where:xx xx = lengthyy yy = checksumzz zz = boot option
31Utilities To Go To access the boot table: Hex6x (available in CGT) Need an rmd file to provide details to hex6xThe output file is in the boot table formatIf the EVM is set in little endian mode, convert the boot table to big endian mode (used by the RBL) using the bconvert64x utility (available in MCSDK).Convert to an I2C format (to be loaded into the EEPROM) using the b2i2c utility (available in MCSDK).Append the boot parameter table to the boot table using romparse (Available in MCSDK), which uses a map file to retrieve the boot parameter tables.
32SPI BootSame as I2C modeThe only difference is that instead of pages, the NOR flash is selected based on the chip select.
33Ethernet bootThe 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.
34SRIO BootRBL configures the SRIO to operate both in messaging mode and DirectIO mode.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.
35PCIe 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.
37Booting 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 CorePacs are 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 CorePacs out of IDLE.
39Second 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.
40Second 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.
42Intermediate 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 bootNAND bootNOR bootIn 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.
43For More InformationFor more information, refer to the Bootloader for KeyStone Devices User's Guide.For questions regarding topics covered in this training, visit the support forums at the TI E2E Community website.
45Boot Runtime – Ethernet The SERDES, SGMII and switch are not configured if the options field of the Ethernet boot parameter table indicate initialization is bypassed. This will be the default case when the boot is initiated by hard or soft reset, reset isolation has been enabled, and the devices are powered up and enabled.SERDES: The boot ROM programs the SGMII_SERDES_CFGPLL register, the SGMII_SERDES_CFGRX registers (both lanes) and SGMII_SERDES_CFGTX register (both lanes).SGMII: The SGMII is enabled in full duplex mode, gigabit rate. Broadcast packet reception is enabled based on the boot parameter table.QMSS: The QMSS is configured to manage descriptors using a single memory region. Each descriptor is sized to 48 bytes with extended packet information block present.PASS: A custom firmware load is used for PASS. This load simple directs all received packets to the CPDMA, using flow configuration 0.Interrupt System: Polling is used to detect packet arrival in queue 896, so interrupts are not configuredAfter initialization, the device will broadcast a ready frame containing its device ID and MAC address.The Ethernet Host is responsible to receive the ready frame and follow up with the boot packets to the DSP using the device’s MAC address or ID. If Broadcast Rx is configured, then the host can broadcast a common image to all DSPs.The image is converted into a boot table and sent in packets from host to the DSP where the boot code reconstructs the image.
46Boot Runtime – Serial RapidIO SRIO boot behaves as supported on previous devices for DirectIO mode. For Nyquist-Shannon, boot using Messaging Mode is supported as well, provided the host sends Ethernet IP messages.The boot ROM will not configure the SERDES or SRIO if the boot options in the SRIO boot parameter table show that configuration bypass is enabled. This will be the case in hard or soft reset when reset isolation is enabled and the SRIO and SERDES have already been enabled.SERDES and SRIO register configurations are based on templates. Basic values are taken from the template and modified to match the provided input frequency, number of lanes, and output frequency.SERDES: The SERDES is configured before the SRIO. The boot ROM programs the SRIO_SERDES_CFGPLL register, the SRIO_SERDES_CFGRX registers, and the SRIO_SERDES_CFGTX registers. The values programmed into these registers are based on the configurable parameters in the SRIO boot parameter tables.In addition, for message booting over SRIO, the RIO_RXU_MAP00, RIO_RXU_MAP00_H and RIO_RXU_MAP00_QID registers are programmed. They are programmed to route all messages (promiscuous) to queue 896 using flow ID 0.QMSS: The QMSS is configured to manage descriptors using a single memory region. Each descriptor is sized to 48 bytes with extended packet information block present (EInfo). The receive configuration is identical to that of Ethernet and a single function is used for both configurations.For DirectIO mode, the DSP will poll the boot magic address. Once this address is populated, the DSP branches to the address specified in the boot magic address. For Messaging Mode, the operation is equivalent to Ethernet Boot
47Boot Runtime – SPIThe SPI is configured as directed by the boot parameter table. The SPI is operated through direct register reads and write.The boot ROM initializes the peripheral and begins reading blocks of data starting at the address specified in the boot parameter table (see Table 34). The ROM reads the data in blocks. Each block consists of two 16 bit word headers.The data in the blocks must contain boot table data. The data might also start with new boot parameter table. The new boot parameter block would specify a higher clock speed and a new boot address for the actual boot data.
48Boot Configuration – PCI Express The bootloader configures the base address registers, the number of windows, and their size.The PCIe power-up is configured through the external pin.If the PCIe boot is the primary boot, the BAR size configuration is driven by the BAR config fields as below.Once the BAR configurations are done, the host can access to the memory map of the DSP and image is loaded into the memory.At the end the boot magic address is also set to the entry point of the image.The DSP is brought out of IDLE by either a MSI interrupt or a legacy interrupt. (See PCIe user guide for further details.)
50Boot Runtime: I2C Master Mode Master Mode: In master mode the boot ROM reads blocks from the I2C EEPROM. The first 4 bytes are the header with the size of the block and the checksum.The first block will be a Boot Parameter Table. They will set the proper PLL configuration for the core clock settings. Each block will be 128 bytes in size and the boot parameter table will specify the next block to read. The next block can be another boot parameter table or a boot table or a boot config table.In case of Boot Table Mode, blocks are read from the I2C, the 4 byte header is stripped, and the data is passed to the boot table processing function. The boot code will parse the boot table and determines the start address. The code then populates the BOOT_ADDRESS register. Once the boot table is completely parsed the boot code branches to the address in the BOOT ADDRESS register and brings the DSP corePAC out of idle and execute the code.In Config Table Mode, the data read from the I2C contain configuration tables. Each element in the table consists of three 32 bit fields.This mode is typically used to poke registers needed before boot can be run, or to execute functions from a previously loaded boot.Each entry in the table falls into one of three types.Standard Entry for read-modify-write of an addressBranch entry for a function call to the specified addressTable Terminate to end and re-run boot
51Boot Runtime I2C Master-Broadcast Mode Master-Broadcast: If enabled, the DSP will re-broadcast the boot image loaded from I2C to all passive devices. This is used in case we have multiple DSPs in a same system and one DSP acts as a master driving the other DSPs.
52Boot Runtime I2C Passive Mode Passive Mode: the boot ROM operates the I2C device in receiver mode.The header format for passive mode is 19 xx xx yy yy zz zz . Where 19 is the I2C slave address, xxxx is the length, yyyy is Checksum and zzzz is the boot option.The boot option can be again boot parameter table, boot table or a boot config table.