SPRACN3 September   2019 66AK2E05 , 66AK2H06 , 66AK2H12 , 66AK2H14 , 66AK2L06 , AM5K2E02 , AM5K2E04

 

  1.   Using ARM ROM Bootloader on Keystone II Devices
    1.     Trademarks
    2. 1  Keystone2 Boot loader Overview
    3. 2  Boot Examples Package Download
    4. 3  Software Dependencies
    5. 4  Supported Hardware
    6. 5  Software Features
    7. 6  Directory Structure
    8. 7  Building the Examples
    9. 8  Description of the Examples
      1. 8.1 Single Stage Boot Examples
      2. 8.2 Multi-Stage Boot Example
      3. 8.3 Boot Media-Specific Details
        1. 8.3.1 SPI Boot Example
        2. 8.3.2 I2C Boot Examples
        3. 8.3.3 NAND Examples
        4. 8.3.4 UART Boot Examples
        5. 8.3.5 Ethernet boot examples
        6. 8.3.6 K2E Ethernet Boot Errata Workaround
      4. 8.4 Flashing and Running Boot Examples
        1. 8.4.1 Dip Switch Settings
        2. 8.4.2 Running I2C EEPROM example
        3. 8.4.3 Running SPI NOR Example
        4. 8.4.4 Running NAND Example
        5. 8.4.5 Running UART Example
        6. 8.4.6 Running Ethernet Examples
    10. 9  Boot Utilities
    11. 10 Frequently Asked Questions (FAQ)
    12. 11 References

10 Frequently Asked Questions (FAQ)

Question: Where can I find the details for ROM call tables that define the ROM re-entry and other calls to ROM functions?

Answer: The details of the ROM call tables are covered in Table 1.

Table 1. ROM Function Table

Memory Address Function Name Details
00001000 _romtMonitorFunction Install Monitor code
00001004 _romtBootReentry BootROM re-entry function
00001008 _romtEnableModule Power up a module
0000100C _romtDisableModule Power down a module
00001010 _romtEnterHibernation Enter hibernation
00001014 _romtCleanupHibernation Cleanup hibernation
00001018 _romtConfigPll Configure PLL
0000101C _romtDelay Delay
00001020 _romtDeviceFreqMhz Set device frequency specificed by device variant
00001024 _romtArmNum Return the ARM number (will only execute as supervisor
00001028 _romtTetrisPsc Transition the Tetris psc
0000102c _romtCacheClean Perform a cache clean
00001030 _romtPscSetState System PSC set state
00001034 _romtMainEmif4Cfg (1) Emif 4 configuration based in the DDR configuration table
  1. This function is available only on K2E devices. K2H devices do not provide this ROM call function.

Question: How to obtain the DDR configuration table for my device?

Answer: Create a GEL file for your platform that can initialize the DDR based on the clocks on you platform and the timings required by the DDR3 memory you have used on the platform. If you have the GEL file created with the stable configuration, the GEL DDR init function will contain the configuration of DDR controller settings that can be translated to DDR configuration table. For example, check, how the DDR configuration table has been created for K2E devices by comparing it with the DDR settings in the K2E EVM GEL file provided in the emulation package.

Question: How can I run the Boot utilities in Linux environment?

Answer: You can use the pre-built windows based boot utilities in Linux using a utility called "wine". There are no known issues with this usage but the package is not designed to build in the Linux environment in its current form.

Question: How to debug Booting from different boot modes?

Answer: There are multiple ways to debug booting on K2 devices. Some of these techniques are discussed below:

  • Check the DEVSTAT settings and the boot parameter table loaded in by the Boot ROM:

    • First, and the simplest way to check if your device is setup to boot correctly, is to connect to the device using an emulator using CCS and connect to Arm Core 0. Ensure that you remove the GEL files that are typically used to initialize the DDR as they will override the settings done by the Boot ROM. In the memory browser, check the value in DEVSTAT register. For the location of DEVSTAT register, see the device-specific data manual. The interpretation of the value in the DEVTAT register will be provided in the DEVSTAT Boot Mode Pins ROM Mapping section. If this value is accurately based on you boot switch settings, look at the memory location that contains the boot parameter table for the device. The location of the boot parameter table can be found in the ARM Boot RAM Memory Map section in the device-specific data manual. The definition for the boot parameter structure varies based on the boot mode. You can refer to the boot media specific parameter table in the data manual or in the tiboot.h file for the device. Ensure that you are specifying the correct REF clock settings for your platform and are not over clocking the device at the time of boot.

  • Check for CS/CE on flash media and ping messages on slave boot modes.

    • If the DEVSTAT and boot specific parameter table are loaded as expected, you can check the hook up of the boot media by ensuring that there is activity on the Chipselect or Enable of the flash media or for slave boot media check for ping messages that typically are outputted from the device. For UART boot, the device transmits a ping character "C" on the device. For ethernet, the device sends a BOOTP (ready packet) from the port, and so forth. This should indicate that the device and the boot media are configured correctly.

  • Check the boot image format.

    • Typically for blob boot, the K2 devices load the image at the base of MSMC and for GP boot formats the device loads the image specified by the GP header. Therefore, connect to the device at the memory location where you expect you boot image to load and confirm that the image is loaded by the ROM. To simplify this process, you can also choose to load the symbols from your application binary and see if the code in that location correlates with the data in the memory location. You can also compare your boot image with images built in this boot examples package to ensure that it is in the correct format.

  • Debugging multistage boot:

    • In order to debug the multi-stage boot, you can add a large delay or a while loop in each of the stages so that you can single step through the code after each stage has booted. The delay or the while loop allows you to connect to the device and then step through the code loaded by the boot ROM. To view symbols, you can add symbols in CCS using Run->Load Program->Load Symbols. This does not add the actual code over the emulators but just the symbols from the application.