• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 1459 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.

[66AK2H14] Reserved bits for DEVSTAT

Naoki Kawada
Guru 19890 points


Hi,

My customer has a problem with boot failure on their costom board -- No responding in secondary core pack boot monitor. Please note it looks working correctly on EVM. The following is U-boot commands on EVM:

# tftpboot ${addr_mon} skern-k2hk.bin
# mon_install ${addr_mon}
skern_init(): Message2 from Secure Mode
Core freq - 0x0bebc200
## installed monitor, freq [200000000], status 0
K2HK BBCPU # mon_power 1 1
>>>> skern_poweron_cpu >>>>
core 1 powered on successfully
K2HK BBCPU # [CPU-00000001]Message2 from Secure Mode
Core freq - 0x0bebc200

But on their target board, it is not working.

K2HK BBCPU # mon_install ${addr_mon}
skern_init(): Message2 from Secure Mode
Core freq - 0x0bebc200
## installed monitor, freq [200000000], status 0
K2HK BBCPU # mon_power 1 1
>>>> skern_poweron_cpu >>>>
core 1 powered on successfully
K2HK BBCPU #

They are trying to debug this issue, and noticed that a reserved bit (bit22) was set on DEVSTAT register. They are not sure this is really related to this issue, but could you please let me know what is meant by bit22 on DEVSTAT register ?

EVM:
0x02012005 on DEVSTAT, and it worked fine.

Custom Board:
0x02412005 on DEVSTAT, and it did not work. A one was set on bit22 (reserved).

Well I thought the following thread might be the same issue, but my customer had confirmed the power domain looked correctly on secondary core. So it seems different problem.

https://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/511278

Best Regards,
Naoki

  • 0
    TI__Guru* 81335 points
    We will check with factory team and get back to you as soon as possible. Thank you for your patience.
  • 0
    TI__Guru* 81335 points

    Hi Naoki Kawada,

    1. Please describe the boot failure on the custom board.
    Have they tried booting SMP Linux on target? If Yes, Can you please attach the complete log for review?

    2. Do they see this issue with all of their custom boards?

    3. From the above log, I understand that you are using same u-boot.bin for EVM and custom boards and custom board is configured like EVM.
    Can you try to boot with pre-built binaries of latest Processor SDK(u-boot, boot monitor) and see the behavior?

    Please find the latest SDK download link below my signature. Thank you.

  • 0 in reply to Raja
    Guru 19890 points

    Raja said:
    1. Please describe the boot failure on the custom board.
    Have they tried booting SMP Linux on target? If Yes, Can you please attach the complete log for review?

    This problem is related to boot monitor, which will be initiated from u-boot. After the boot monitor completes its work, the control comes back to u-boot again, and then SMP linux will be booted as usual. You might be saying here about SMP linux log, but please note the problem happens on boot monitor before starting SMP linux kernel.

    Raja said:
    2. Do they see this issue with all of their custom boards?

    They have only few boards, but as of now, 2/2 on custom board.

    Raja said:
    3. From the above log, I understand that you are using same u-boot.bin for EVM and custom boards and custom board is configured like EVM.
    Can you try to boot with pre-built binaries of latest Processor SDK(u-boot, boot monitor) and see the behavior?

    Some parts of the code has been modified for their custom board, for example, some GPIOs, DDR configurations,SGMII connection and etc.

    Well, I got some further information from my customer. It seems slave cores were working in big endian mode even though the system has been configured as little endian. They have confirmed this fact as below:

    1. register branch address for core1, where that entry has an infinite loop for debugging.
    2. invoke boot monitor for core1 and confirm PC comes to the above infinite loop.
    3. halt CPU via ICE and check both CPSR.E and SYSCTL.EE. And confirm these indicates big endian (1)
    4. Also, the following register was confirmed. core1 seems like working as big endian.

     CPSR.E = 1 
     SCTLR = 0x02C50078 
     SYSENDSTAT = 0x00000001
     ARMENDIAN_CFG0_0,1,2 = {0001c000 00000006 00000000} 4MiB
     ARMENDIAN_CFG1_0,1,2 = {00020000 00000009 00000000} 32MiB
     ARMENDIAN_CFG2_0,1,2 = {000bc000 00000004 00000000} 1MiB
     ARMENDIAN_CFG3_0,1,2 = {00210000 00000008 00000000} 16MiB
     ARMENDIAN_CFG4_0,1,2 = {00023a00 00000005 00000000} 2MiB
     ARMENDIAN_CFG5_0,1,2 = {00240000 00000006 00000000} 4MiB
     ARMENDIAN_CFG6_0,1,2 = {01000000 00000000 00000000} 64KiB
     ARMENDIAN_CFG7_0,1,2 = {ffffff00 00000000 00000000} 64KiB

    Please remember the system has been configured as little endian. DEVSTAT was also indicated as little endian. But, core1 looks working as big endian... Why this can happen ?

    Just for your information, but the same thing was also tested on EVM and they verified the core1 was working in little endian mode on the condition of boot configuration for little endian.

     CPSR.E = 0  (※)
     SCTLR = 0x00C50078  (※)
     SYSENDSTAT = 0x00000001
     ARMENDIAN_CFG0_0,1,2 = {0001c000 00000006 00000000} 4MiB
     ARMENDIAN_CFG1_0,1,2 = {00020000 00000009 00000000} 32MiB
     ARMENDIAN_CFG2_0,1,2 = {000bc000 00000004 00000000} 1MiB
     ARMENDIAN_CFG3_0,1,2 = {00210000 00000008 00000000} 16MiB
     ARMENDIAN_CFG4_0,1,2 = {00023a00 00000005 00000000} 2MiB
     ARMENDIAN_CFG5_0,1,2 = {00240000 00000006 00000000} 4MiB
     ARMENDIAN_CFG6_0,1,2 = {01000000 00000000 00000000} 64KiB
     ARMENDIAN_CFG7_0,1,2 = {ffffff00 00000000 00000000} 64KiB

    Best Regards,
    Naoki

  • 0 in reply to Naoki Kawada
    Guru 19890 points
    Any response ?

    Well, they are still debugging the issue and now checking the differences between EVM and their custom board.
    And they found that VPP pins were being connected to 1.8V even though data sheet stated these pins should be left unconnected.
    Also, hardware design guide says in 2.2.9.3 VPP that VPP pin is used only for secured device.
    ==> Question : What can happen when VPP is powered on with non-secured device ? Is this related to this issue ?
    On EVM, it seems BMC software controls VPP via SOC_VPPB_EN signal and keeps the line as 0V.
    They are wondering if they would be able to change the BMC software to provide 1.8V to VPP just for debug purpose
    on NON-SECURED device and see what happens. Is it okay for them to provide the power to VPP on NON-SECURED device ?
    Also, do you have any suggestion for the modification(s) in BMC software ? They are concerned there might be some
    requirements for the timing for VPP power-on, so if you would be able to suggest, it would be helpful.
  • 0 in reply to Naoki Kawada
    TI__Guru** 116100 points
    Dear Naoki,
    FYI, Experts are working on this post, surely you would reply soon from them.
  • 0 in reply to Titusrathinaraj Stalin
    TI__Mastermind 46460 points

    Naoki-san,

    VPP is only used when programming fuses on secure devices.  Even then it must have very carefully controlled power sequencing.  Customer boards must be power VPP.  It is possible but not likely to be the cause of the problems seen.  Random fuse changes can have unpredictable and potentially catastrophic results.

    Tom

  • 0 in reply to Tom Johnson 16214
    TI__Mastermind 46460 points

    Naoki-san,

    Please have customer check BOOTMODE_RSVD which is B31 and the same pin as GPIO15.  The DM indicates that this pin must be pulled down to VSS by a resistor during latching of the boot configuration.

    Tom

  • 0 in reply to Tom Johnson 16214
    Guru 19890 points
    Hi Tom,

    They confirmed BOOTMODE_RSVD was actually configured as high and they fixed it to be low. As a result, the problem was disappeared !!
    Thank you for your great help.

    So last question about VPP.... VPP connection was not related to the issue, but I believe VPP pin should be left unconnected with non-secured device and they should fix it also on their custom boards. Is my understanding correct, right ? They are asking what can happen when VPP is powered as is. Maybe, your answer for the question is "Random fuse changes can have unpredictable and potentially catastrophic results.", but let me clarify shortly.

    Best Regards,
    Naoki
  • 0 in reply to Naoki Kawada
    TI__Mastermind 46460 points

    Naoki-san,

    I have nothing to add.  VPP must not be powered on their product.  Results are indeterminate.

    Tom

  • 0 in reply to Tom Johnson 16214
    Guru 19890 points
    OK, understood. Thank you for your reply. Best regards, Naoki