• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 100 subscribers
  • Views 520 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Selecting a default DeviceID to boot C6474 over RapidIO

Mathew Jones
Prodigy 20 points

I would like to understand how I can set default DeviceIDs for several 6474 DSPs so that a host can communicate with each DSP in turn and boot it (by sending its firmware with DirectIO operations followed by a Doorbell message).

I can boot a single 6474 over RapidIO without problems but now would like to understand how a default DeviceID can be set. The Bootloader Users Guide (sprug24) section 2.4.5 says that BOOTMODE[1:0] selects the rapidIO boot mode and BOOTMODE[2] is used as the MSbit and CFGGP[2:0] as the 3 LSbits for the Device. It then goes on to say "If BOOTMODE[2]:CFGGP[2:0] is 0b1111, the default value of the device ID is 0xFF or 0xFFFF, and it must be configured/assigned by the host (maintenance packet to DEVICEID_REG1); otherwise, device ID = 2 + BOOTMODE[2]:CFGGP[2:0]."

To me this doesn't make sense since all 4 BOOTMODE bits are required to select the boot mode for the DSP, with values 8,9,10,11 used for RapidIO booting. So although bits [1:0] do select the specific RapidIO boot mode, BOOTMODE[2] is always 0, meaning that BOOTMODE[2]:CFGGP[2:0] can only be 0b0000 to 0b0111.

Does this mean the DeviceID can never be set to 0xff / 0xffff? And are its values in fact 2 + 0 through to 2 + 7, i.e. 0x02 to 0x09 ?

Any ideas anyone, or am I just missing something obvious?!?!?

  • 0
    TI__Mastermind 23525 points

    Hi Mathew,

     

    Hopefully this will make more sense:

    *editted to fix mistake in below chart

    B3 B2 B1 B0

    1    0    0   0   - rapid I/O boot configuration 0

    1    0    0   1   - rapid I/O boot configuration 1

    1    0    1   0   - rapid I/O boot configuration 2

    1    0    1   1   - rapid I/O boot configuration 3

     

     

     

    CFG[3:0]    BASE_ID

    0000                      0x0002

    0001                      0x0003

    0010                      0x0004

    0011                      0x0005

    0100                      0x0006

    0101                      0x0007

    0110                      0x0008

    0111                      0x0009

    1000                      0x000A

    1001                      0x000B

    1010                      0x000C

    1011                      0x000D

    1100                      0x000E

    1101                      0x000F

    1110                      0x0010

    1111                      0xFFFF

     

    We don't assign BASE_IDs of 0x0000 or 0x0001 because they are reserved for system hosts.

     

    Regards,

    Travis

  • 0 in reply to tscheck
    Prodigy 20 points

    Thanks Travis,

    That does make sense, certainly from the point of view of 0x0000, 0x0001 as reserved IDs for system hosts
    and 0xffff as the ID which endpoints should respond to Maintenance Packets from power-up.

    Is your numbering correct, because there are a few values missed out?

    It might be as follows:
    B2:CGCCP[2:0]    BASE_ID

    0000                       0x0002
    0001                       0x0003
    0010                       0x0004
    0011                       0x0005
    0100                       0x0006
    0101                       0x0007
    0110                       0x0008
    0111                       0x0009
    1000                       0x000A
    1001                       0x000B
    1010                       0x000C
    1011                       0x000D
    1100                       0x000E
    1101                       0x000F
    1110                       0x0010

    1111                       0xFFFF

    I've found that B2 must be '0' for the 6474 EVM board, otherwise it doesn't appear to enter RapidIO boot mode.
    I don't know whether this is specific to the 6474 EVM or whether it is the 6474 itself, although sprug24 & sprs522 say
    that BOOTMODE values 11xx are reserved, suggesting that B2 can only be 0 for RapidIO Boot modes.

    In either case, I should be OK with the range of vaues 0x02 to 0x09.

    Regards
    Mathew

     

  • 0 in reply to Mathew Jones
    TI__Mastermind 23525 points

    Mathew,

     

    You are absolutely right, my table had mistakes (my binary counting needs work), but I corrected it above.  The key is that it assigns DEVNUM[3:0] + 2 as the default BASE_ID, where DEVNUM[3:0] is noted as CFG[3:0] in some of the documentation tables.

    And you found a documentation error in section 2.4.5 of SPRUG24. Here it states B2:CGCCP[2:0] is used to assign the BASE_ID value.  This is only true for the C6455 or TCI8682 devices.  For the C6474, it uses DEVNUM[3:0], which are mapped to GPIO[11:8].  This is alluded to in section 2.3, Table 3.  We are updating the C6474 bootloader document, but in the mean time,  you can refer to the following: http://focus.ti.com/lit/ug/spruea7d/spruea7d.pdf referring to the TCI6487/TCI6488 boot sections.  It is identical to the C6474 boot, but the document is more up to date.  Also, you are right that B2 is used specifically for the boot mode on the C6474, so it must be 0.  This wasn't the case on the C6455.

    Regarding the C6474 EVM, you should be able to set the DEVNUM[3:0] using the USER Configuration EEPROM.  Refer to the EVMC6474_TechRef guide from Spectrum Digital.  You will have to program the USER EEPROM with the settings you want, essentially to change only the DEVNUM settings you will have to change the Byte 1 of the C6474 Boot and Configuration section of the EEPROM.  You will have to set SW4 position to ON to select the User EEPROM instead of the factory one.

    Regards,

    Travis

  • 0 in reply to tscheck
    Expert 1070 points

    Great info! I have been stumbling over meaning of CFGGP[], CFG[] and DEVNUM[] .Now it makes sense (I think, please confirm): For the C6474, DEVNUM[3:0] is what is referred to as CFG[3:0] in SPRAAV8, and CFGGP[2:0] in SPRUEC6D.

    At this time the documentation is still incorrect. I hope it'll be updated (provided what I'm stating above is correct).

    Regards,

    Dirk

  • 0 in reply to Dirk Buijsman
    TI__Mastermind 23525 points

    Yes, that is right.  The SPRUEC6D does actually say:

     

    "The configuration pins, DEVNUM[3:0] are referred to as CFG[3:0] in Table 34."

    It is a little confusing though, since in some spots it uses DEVNUM.

     

    Regards,

    Travis

  • 0 in reply to tscheck
    Expert 1070 points

    Thanks for your reply. Another confusing part is that CFGGP[2:0] is used on the next page of SPRUEC6D in section 5.4.2.2:

    "The DSP calculates the address of boot parameter block to load based on the value of the CFGGP[2:0] bits of the Device Status Register (DEVSTAT) as follows: address = 0x80 * CFGGP[2:0]."

    My guess is that that's a copy paste error from the C6455 section. 

     

    Regards,

    Dirk

  • 0 in reply to Dirk Buijsman
    TI__Mastermind 23525 points

    Dirk,

    Good catch.  So to be clear....

    The C6455 device didn't use the concept of DEVNUM at all in the DEVSTAT register, so besides the normal BOOTMODE[3:0] pins, it used the general purposes config input CFGGP[2:0] to determine SRIO deviceID on boot.  Described well in chapter 6 of spraav8 and table 16.

    The C6474 device used DEVNUM, so besides the BOOTMODE[3:0] pins, it used the DEVNUM[3:0] to determine SRIO deviceID on boot.

    There are other references in section 6.2 and 6.24, but they are referring to the C6455, but the sentence you highlighted should be changed to   "The DSP calculates the address of boot parameter block to load based on the value of the CFGGP[2:0] bits of the Device Status Register (DEVSTAT) as follows: address = 0x80 * DEVNUM[3:0]."    

    I'll see about getting that fixed in the next release.


    Regards,

    Travis