This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BOOTMODE15 incorrectly specified in Data Sheet (SPRS866E)

Table 5-2 says BOOTMODE15 is pin D24. Table 8-29 says BOOTMODE15 is B31.

It appears Table 8-29 is incorrect in multiple ways. Please advise.

  • Bruce,

    Looks like it is incorrect. I file a litbug to resolve it and get back to you with correct information.

    Thank you for your patience.
  • Bruce,

    You are correct.  The 16 pins listed for BOOTMODE[15:0] in Table 8-29 of SPRS866E are not correct.  This list is the 16 GPIO[15:0] pins.  Previous KeyStone devices mapped BOOTMODE[15:0] onto the pins GPIO[15:0] but 66AK2H did not follow that pattern.  This problem has been reported previously and should have been fixed.  We will request a correction.  The pin numbers listed in Table 5-2 are correct.

    Also pay close attention to the note on page 206 right above Figure 8-1.  BOOTMODE[15:0] pins map to DEVSTAT[16:1] bits of the DEVSTAT register.  This mapping also causes confusion.

    Tom

  • Thanks for the info. We will change the schematic and update our hardware.
  • Bruce,
    Please also use the K2HK EVM as a successful sample design for the 66AK2H implementation. This is a functional design that can be used as a model for design and test.
    Tom
  • Another discrepancy in the EVM data is that it shows the ARM_CLK being driven at 125 MHz, but the BOOTMODE for ARM PLL only shows mappings for 100 MHz and below.
  • Bruce,

    Please indicate the table or figure that you are questioning.

    Table 8-28 contains PLL configurations for the ARM PLL.  It shows standard configurations for various reference clock rates up to the maximum input clock rate of 312.5MHz.  Please note that these are not the only valid configurations.  These are the ones that are implemented in the BOOTROM code to support a variety of common applications.

    Table 10-25 in Section 10.5.5 lists the electrical limitations for the ARM PLL reference clock.  It can be any clock frequency from 40MHz (25ns period) up to 312.5MHz (3.2ns period).  The ARM PLL can then use this reference clock to generate almost any frequency to drive the ARM subsystem.  The clock rate provided to the ARM subsystem can be any frequency up to the maximum rating for the device speed grade installed.  The maximum ARM subsystem clock rate relative to the device speed grade is shown in Section 2.5 in Figure 2-1.

    Tom

  • Sorry for the confusion. I meant to say that there is not a 125 MHz entry in Table 8-28, but some documents show the EVM drives the ARM_CLK at 125 MHz. We took our ARM_CLK down to 100 MHz so we could comply with Table 8-28, entry 0b011. It is not clear that 0b011 will work for 125 MHz.
  • Bruce,

    The design does not need to 'comply' with Table 8-28.  If you choose to use a frequency other than one listed, simply choose the next highest.  This will result in the ARM running a little slower at start-up than optimum.  Then the uboot code can reconfigure the PLL for optimum system performance.

    Tom

  • Tom,
    Thanks for the reply. I'm confused by the term "next highest." Should we choose ARM_PLL = 0b011 for ARM_CLK=125MHz?
    Thanks,
    Bruce
  • Bruce,

    No, the next higher frequency.  If your reference clock is 125MHz, the next higher standard configuration is [100] for an input reference clock rate of 156.25MHz.  The equation as shown in Section 8.1.4.1 is:

    CLK = CLKIN × ((PLLM+1) ÷ ((OUTPUT_DIVIDE+1) × (PLLD+1)))

    For a device rated for 1000MHz, this will yield an ARM clock rate of 800MHz with an input clock of 125MHz rather than the expected frequency of 1000MHz if the input frequency were 156.25MHz.

    I have noticed that the PLLD values listed in this Table 8-28 for the 156.25MHz row are not correct for speed grade 800 and 1200.  I will validate that this is a typo.  They are correct in Table 8-27.

    Tom

  • Great. Thanks for your help.
  • Bruce,

    I have verified that the SPRU866E DM table for the ARM PLL is in error.  The values should match the previous SYSCLK PLL table.  I will request a correction.

    Tom