imx6 locks up when jtag used

[deschamp]

I have an issue with interaction between JTAG and the Linux kernel.

I am using a custom board with an imx6Q and an Altera Cyclone V FPGA.

I have been working with this board for over a year without problems.

After updating the Linux kernel, the issue now is that when any JTAG activity is sent to the JTAG chain, the imx6 locks up.

Just scanning the chain will lock up the imx6.

I am not debugging the CPU with JTAG, I am only using it to debug the FPGA (JTAG_MODE pin is pulled high).

This issue just started sometime in the 3.10.31 or 3.10.53 version of the kernel.

I have also tried 3.14 with the same issue.

All build are done using Yocto.

I have confirmed no resets are issued during the scan.

My questions is, what is the relationship between the kernel and JTAG?

Does the kernel run a driver or microcode to control the JTAG port?

I am trying to find a starting point to dig into this more, but having difficulty finding any relationship between the Linux kernel and JTAG.

The Linux kernel hangs with the message :

mxc_ipu mxc_ipu: ERR: [0xd8957200] no-0x350070, timeout:1000ms!

mxc_ipu mxc_ipu: ERR: no-0x350070,ipu_queue_task err:-110

ioct IPU_QUEUE_TASK fail -1mmc2: Timeout waiting for hardware interrupt.

------------[ cut here ]------------

WARNING: CPU: 1 PID: 0 at /media/D/fido/build/tmp/work-shared/wandboard/kernel-source/drivers/mmc/host/sdhci.c:997 sdhci_send_command+0x890/0xe00()

Modules linked in: ofpart cmdlinepart alt_up_pci(O) cfi_probe gen_probe map_rom cfi_cmdset_0020 cfi_cmdset_0002 cfi_cmdset_0001 cfi_util chipreg mtdblock mtd_blkdevs mtd mxc_v4l2_capture ipu_bg_overlay_sdc ipu_still ipu_prp_enc ipu_csi_enc ipu_fg_overlay_sdc ov5640_camera_mipi v4l2_int_device evbug

CPU: 1 PID: 0 Comm: swapper/1 Tainted: G           O 3.14.28_1.0.0_ga-wandboard+g99d36d8 #1

[<80015630>] (unwind_backtrace) from [<800116ec>] (show_stack+0x10/0x14)

[<800116ec>] (show_stack) from [<805db3e8>] (dump_stack+0x7c/0xbc)

[<805db3e8>] (dump_stack) from [<8002f248>] (warn_slowpath_common+0x70/0x8c)

[<8002f248>] (warn_slowpath_common) from [<8002f300>] (warn_slowpath_null+0x1c/0x24)

[<8002f300>] (warn_slowpath_null) from [<80437280>] (sdhci_send_command+0x890/0xe00)

[<80437280>] (sdhci_send_command) from [<80437bf8>] (sdhci_timeout_timer+0x74/0xb8)

[<80437bf8>] (sdhci_timeout_timer) from [<80039254>] (call_timer_fn.isra.33+0x24/0x88)

[<80039254>] (call_timer_fn.isra.33) from [<80039418>] (run_timer_softirq+0x160/0x1e4)

[<80039418>] (run_timer_softirq) from [<8003327c>] (__do_softirq+0x140/0x248)

[<8003327c>] (__do_softirq) from [<8003360c>] (irq_exit+0xb8/0xf4)

[<8003360c>] (irq_exit) from [<8000ed50>] (handle_IRQ+0x44/0x90)

[<8000ed50>] (handle_IRQ) from [<8000856c>] (gic_handle_irq+0x2c/0x5c)

[<8000856c>] (gic_handle_irq) from [<80012200>] (__irq_svc+0x40/0x70)

Exception stack(0xd80c9f50 to 0xd80c9f98)

9f40:                                     d80c9f98 3b9aca00 d61493da 0000062c

9f60: 808a6448 808a6448 ee7260d0 00000000 d57c66d2 0000062c d80c8000 00000000

9f80: 00000017 d80c9f98 00000009 80421f60 00070013 ffffffff

[<80012200>] (__irq_svc) from [<80421f60>] (cpuidle_enter_state+0x54/0xe4)

[<80421f60>] (cpuidle_enter_state) from [<804220a4>] (cpuidle_idle_call+0xb4/0x14c)

[<804220a4>] (cpuidle_idle_call) from [<8000f09c>] (arch_cpu_idle+0x8/0x44)

[<8000f09c>] (arch_cpu_idle) from [<80069530>] (cpu_startup_entry+0x100/0x14c)

[<80069530>] (cpu_startup_entry) from [<10008624>] (0x10008624)

---[ end trace 5827d37a38e6a8fd ]---

[fatalfeel]

Do not need to undefine CONFIG_CRYPTO_DEV_FSL_CAAM

find file

~/myandroid/kernel_imx/drivers/crypto/caam/secvio.c

do this done

wr_reg32(&svpriv->svregs->hp.secvio_intcfg,

                     HP_SECVIO_INTEN_SRC4

                     |

                     HP_SECVIO_INTEN_SRC2

                     |

                     //HP_SECVIO_INTEN_SRC1  //mark here

                     //|

                     HP_SECVIO_INTEN_SRC0);

ps:

/* these are the untranslated causes */

enum secvio_cause {

    SECVIO_CAUSE_SOURCE_0,

    SECVIO_CAUSE_SOURCE_1,

    SECVIO_CAUSE_SOURCE_2,

    SECVIO_CAUSE_SOURCE_3,

    SECVIO_CAUSE_SOURCE_4,

    SECVIO_CAUSE_SOURCE_5

};

/* These are common "recommended" cause definitions for most devices */

#define SECVIO_CAUSE_CAAM_VIOLATION    SECVIO_CAUSE_SOURCE_0

#define SECVIO_CAUSE_JTAG_ALARM        SECVIO_CAUSE_SOURCE_1

#define SECVIO_CAUSE_WATCHDOG        SECVIO_CAUSE_SOURCE_2

#define SECVIO_CAUSE_EXTERNAL_BOOT    SECVIO_CAUSE_SOURCE_4

#define SECVIO_CAUSE_TAMPER_DETECT    SECVIO_CAUSE_SOURCE_5

[fahadusman]

Hello Jesse,

I was able to perform debugging using Jtag after making the change you suggested above. Can you tell what would be the impact of not using HP_SECVIO_INTEN_SRC1.

Thanks.

[deschamp · Accepted solution]

Disabling the camm drivers in defconfig fixed this issue.

I believe this was due to a security setting disabling the JTAG port.

#CONFIG_CRYPTO_DEV_FSL_CAAM is not set

#CONFIG_CRYPTO_DEV_FSL_CAAM_SM is not set

#CONFIG_CRYPTO_DEV_FSL_CAAM_SM_TEST is not set

#CONFIG_CRYPTO_DEV_FSL_CAAM_SECVIO is not set

[Yuri]

  Two possible reasons for the issue :

1) Your system provides some JTAG commands to i.MX6, so that

    i.MX6 JTAG is not fully transparent.

2) Programming / accessing the FPGA via JTAG during any transaction

   between the i.MX6 and the FPGA may influence on this operation.

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[deschamp]

Thanks for the response Yuri

I suspect the first one is the issue, but how would a rebuild of the kernel change anything?

Do you know of any software control or influence of the JTAG port?

I tested the FPGA interaction by not loading the driver, or any module drivers, and scanned the JTAG chain.

The kernel command prompt locked up (became non responsive)

I have a version of the 3.10.31 kernel that works fine, all later builds fail.

Is it possible that JTAG is somehow shutting off internal clocks for the imx6?

Thanks

Joe

[Yuri]

It would be helpful to get a log of JTAG operations just before the crash.

Regards,

Yuri.

[deschamp]

I am able to issue test logic reset TLR and run test idle RTI commands, but issuing select DR scan locks up the kernel.

I have tested in U-Boot and it works fine, only after the kernel starts it is a problem.

Suspecting cross-talk to unused pins, I began to look for unused pins being configured in the kernel, but I do not see any.

I cannot seem to find any drivers or configuration in software (kernel) related to the JTAG port.

Joe