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.

66AK2H/12/06 Cortex A15 problem.

Other Parts Discussed in Thread: 66AK2H06, 66AK2H12

Hi!

We have two custom boards, one with 66AK2H12 and other with 66AK2H06. Both PCB's are identical with the exception of the SoC. 66AK2H12 works fine but have a problem with 66AK2H06 and especially with Cortex-A-15 processors. We can not get connected to the target with CCS(v6.0.1.00040), following error message appears:

arm_A15_0: Trouble Halting Target CPU: (Error -1323 @ 0x94D0) Device failed to enter debug/halt mode because pipeline is stalled. Power-cycle the board. If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.1.600.0)

This happens with both of  66AK2H06 arm processors, however we can connect all the 4 DSP C66xx cores fine.

This leads to the question is there something else different than number of processors with these SoC's?

br,

JV

  • Hi JV
    Making sure I am understand this correctly
    1) 66AK2H12 and 66AK2H06 , same board design, just drop in replace H06 instead of H012 and same emulator setup?
    2) On 66AK2H12 you are able to connect to all 8 DSPs and 4 ARMs?
    3) On 66AK2H06 you are able to connect to all 4 DSPs but not able to connect to ARMs?

    Please confirm?
    Regards
    Mukul
  • Hi Mukul

    1,2 and 3 confirmed. We can not get 66AK2H06 ARMs connected, thus measurements (clk, voltage etc.) seem to be correct.

    br

    JV
  • JV,

    Did you run any GEL files during connection?

    If so, can you turn off the GEL commands and try connection again.

    If not, please try the so-called Wait-In-Reset debug mode to halt the target at the very beginning of reset code after a reset. Then, you can step over the code to see what might be wrong.

    Here are the instructions:

    1. After you launch the target configuration and before you connect to any targets <DSP or A15>.
    2. In the debug window, right click on the targets <DSP or A15> you are going to connect to.
    3. Then, enable wait-in-reset mode by checking mark the option - "Enable Halt On Reset".
    4. Issue a CPU reset to the target.
    5. Then connect to that target. Ideally, you will see that the CPU is halt at the very first instruction of reset code.

    Regards!
    Wen
  • Hi all!


    We are able to connect to target now and boot u-boot in 06. Problem was that we had wrong initial voltage setting, we found solution from errata(SPRZ402B) page 58.

    But now we are facing next issue. In 06 we can not get kernel started. We use same code(u-boot and kernel) in both SoCs but only 12 is working and 06 is halted when starting kernel. U-boot works fine and when it tries to start kernel it is halted with message Starting kernel... and nothing after that.

    I have tried with clean build and same thing, 12 works but 06 does not. I enabled lower level kernel debug also, but it only shows one line more, Uncompresing Linux message.

    What could be wrong? One thing I can think is that u-boot and kernel are not compatible in 06, but they are certainly in 12 because it works.

    Are the machine IDs same for 06 and 12?

    Both boards passes mtest in u-boot.

    Our code is based on MCSDK 03.00.04.18(TCI6638_EVM)

    Like said before, PCBs are identical only Socs are different.

    I hope someone could check out this because solution will reduce significantly our R&D costs.


    br,

    JV

  • Clarification to the previous post, correct LL_DEBUG message is Uncompressing Linux ...done, booting the kernel.
    And then nothing after that.

    br,

    JV
  • JV,

    The 66AK2H06/12/14 Multicore DSP+ARM KeyStone II SOC Errata (Revs 1.0, 1.1, 2.0) (Rev. B) shows all 66AK2H06/12/14 share the same Device ID (also called JTAGID) as following:

    Silicon Revision 66AK2H06/12/14 JTAGID Register
    (address location: 0x0262_0018)
    1.0 0x0b98_102f
    1.1 0x1b98_102f
    2.0 0x1b98_102f

    So, it is not possible for SW to distinguish the device types during run-timing based on device ID on these devices.

    Since 66AK2H12 contains four A15 cores, and 66AK2H06 has only two A15 cores, and SW cannot distinguish the number of A15 cores during run-time, my guess is, the Kernel need to be statically built for specific device <66AK2H06 or 66AK2H12>. If that is true, it explain why the Kernel image works for 66AK2H12 won't work for 66AK2H06.

    To be sure on this, I have escalated this question to our Kernel team for confirmation.

    Regards!
    Wen
  • JV,

    Our SW team is going to verify a couple of possibilities for this issue with a setup similar, and we will let you know the solution ASAP.

    Meanwhile, you can also try to build the linux kernel yourself with following modifications - change the k2hk.dtsi file in linux kernel source (arch/arm/boot/dts), from the default configuration for k2hk-evm used in the MCSDK as 4 ARM cores and 8 DSP cores (the 66AK2H12 device) to 2 ARM cores and 4 DSP cores (the 66AK2H06 device) by removing configuration for cpu@2 and cpu@3 and dsp4-dsp7.

    Regards!
    Wen
  • Hi Wen!

    I noticed also that there were too many processors enabled in device tree, but disabling all the 66AK2H12 specific processors did not help either, still could not get 66AK2H06 boot kernel, thus binary files are same.

    br,

    JV

  • For K2H06 platform, the following changes are needed

    1)      Set up cross-compilation environment per User’s Guide (http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Tools#Linaro_toolchain)

    2)      Git clone the kernel per User’s Guide (http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Exploring#Linux_kernel_and_the_device_tree_blob_build_instructions)

    3)      Edit keystone-linux/arch/arm/boot/dts/k2hk.dtsi

    Comment out cpu@2, cpu@3, and dsp4-7 sections

    4)      Rebuild the dtb file per User’s Guide

    $ make keystone_defconfig

    $ make k2hk-evm.dtb

    5)      Copy keystone-linux/arch/arm/boot/dts/k2hk-evm.dtb to the tftp server

    6)      Git clone the boot monitor per User’s Guide (http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Exploring#Boot_Monitor_Build_instructions)

    7)      Edit makedefs and change the number 4 to 2 in line 55

    ARM_NUM_CORES_K2HK=2

    8)      Rebuild the boot monitor

              $ make clean

              $ make k2hk

                (note: this differs from wiki page which is needed)

    9)      Copy skern-k2hk.bin to tftp server

    10)   Boot the EVM with these 2 new files and Kernel will come up

  • Hi Rex!

    Thank you for your answer. Now 06 SoC boots.

    br,

    JV