• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 98 subscribers
  • Views 7582 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.

Methods to disable JTAG interface from software on beaglebone black

Cameron Moree
Prodigy 145 points

Hi

I am wondering how to disable the ability for the JTAG to function from software on a beaglebone black (AM3359AZCZ100). I don't necessarily need to prevent JTAG functioning after doing a power off/on and attaching right away, only preventing the JTAG from attaching while it is already powered on and running my software.

So far I have seen that there is a register to disable it that is apart of trustZone, for example the so called "secure debug enable register".

However I'm not entirely sure if I'm able to use it, or how to go about using it to prevent an external debugger attached via JTAG.

If that is not possible, I've been considering other possibilities, i've read that on some boards people were able to remap the JTAG pins to function as GPIO pins, preventing JTAG from working. If that is possible on the beaglebone black how would you go about doing that?

Another possibility is the fact I was having issues originally getting my JTAG to function, and I tracked it down to have something to do with the linux kernel power management probably related to the "wait-for-interrupt" low power state. Disabling the kernel option "CONFIG_PM_RUNTIME" made my debugger (openocd) start functioning again. So if the other methods are not possible, perhaps I can use whatever caused this bug to prevent JTAG from functioning. I'm just wondering if this issue was only a bug in openocd, and that it would still be possible to debug given proper software.

Anyway any ideas would be appreciated!

  • 0
    TI__Guru**** 393215 points

    Hi Cameron,

    There is no way to disable the AM335X JTAG port. The only sure way is to leave the pins unconnected on the PCB.

  • 0 in reply to Biser Gatchev-XID
    TI__Genius 15510 points

    Maybe when your JTAG didn't work it might have been that the clock for the debug subsystem was disabled. Look in the TRM for the register CM_WKUP_DEBUGSS_CLKCTRL. When the lower two bits are 0, the debug subsystem is disabled. I still agree with Biser, just don't put a header on the board.

    Steve K.

  • 0 in reply to Steve Kipisz
    Prodigy 145 points

    Steve Kipisz said:

    Maybe when your JTAG didn't work it might have been that the clock for the debug subsystem was disabled. Look in the TRM for the register CM_WKUP_DEBUGSS_CLKCTRL. When the lower two bits are 0, the debug subsystem is disabled. I still agree with Biser, just don't put a header on the board.

    Steve K.

    Well,the idea is to prevent an attacker from getting access, so they would put the header on the board. :-P

    Anyway, I will look into exactly what CM_WKUP_DEBUGSS_CLKCTRL is/does thank you.

  • 0 in reply to Steve Kipisz
    Prodigy 145 points

    So I set the lower two bits of CM_WKUP_DEBUGSS_CLKCTRL and indeed, my JTAG does stop working, however reseting the board still appears to work...?

    Do you know if its possible to set the two bits back/get it working again from the external JTAG?

  • 0 in reply to Cameron Moree
    TI__Genius 15510 points

    I don't think so since the debug subsystem is disabled.

    Steve K.

  • 0 in reply to Cameron Moree
    Mastermind 8040 points

    The register you're looking for is CTRL_SEC_TAP_CTRL, located at offset 0x180 in the control module.  It has the following allocation of bits:

    Bit Type Reset
    value    		 Description
    0 read/write 1 DebugSS DAP access
    1 read-only 0 (unused)
    2 read/write 1 Wakeup-M3 DAP/debug access
    3 read/write 1 Test TAP access
    4 write 1 to clear 1 (purpose unknown to me)
    5-8 read-only 0 (unused)
    9 read/write 1 Cortex-A8 debug access
    10-30 read-only 0 (unused)
    31 write 1 to set 0 Lock register (makes all bits read-only)

    The register is warm-reset insensitive; only power-on reset restores it.

    Both bits 0 and 9 are needed for halting debug of the cortex-a8.  Bit 0 allows access to debug interconnect (where the memory-mapped debug registers live) and also the L3 interconnect (although this can be futher limited using the firewalls).  Bit 9 allows setting the "debug enable" (DBGEN) bit of the cortex-a8 via JTAG.  If bit 9 is set but bit 0 is cleared this would still allow a debug monitor to operate if it has some way (outside of JTAG) to communicate with the debugger, e.g. via network.

    Not sure whether the "Test TAP" is for boundary scan, DFT, or both.

  • 0 in reply to Matthijs van Duin
    Prodigy 145 points

    Just trying this out now, I don't appear to be able to set any of these registers from memory mapped I/O (although I can read out the register)

    Is it possible to modify this register from MMIO? (if I am not making sense, I basically mean, is it possible to flip these bits specifically bit 9 without connecting via JTAG?)

    I tested and I could modify them when halted with the JTAG, so at least I know it does what you described... :-)

  • 0 in reply to Cameron Moree
    Mastermind 8040 points

    It should be, as long as you mind the annoying restriction that the control module disallows unprivileged writes.

  • 0 in reply to Steve Kipisz
    Mastermind 8040 points

    Cameron Moree said:

    So I set the lower two bits of CM_WKUP_DEBUGSS_CLKCTRL and indeed, my JTAG does stop working, however reseting the board still appears to work...?

    Do you know if its possible to set the two bits back/get it working again from the external JTAG?

    Steve Kipisz said:
    I don't think so since the debug subsystem is disabled.

    The clock provided by CM_WKUP_DEBUGSS_CLKCTRL is not required for access to ICEPick or the Wakeup-M3, and through the Wakeup-M3 you can access PRCM and restore the clock to DebugSS.

  • 0 in reply to Matthijs van Duin
    Mastermind 8040 points

    Also, the fact that CM_WKUP_DEBUGSS_CLKCTRL is apparently not overridden by a "force clock active" request from ICEPick is something I would consider to be a chip erratum, and not something one should rely on.

    When PRCM doesn't properly honor power/clock requests from ICEPick, debugging power-state transitions / low-power states becomes rather problematic. As a contrasting example, if I understand correctly a debugger can even attach to an OMAP (3 or later) even when it is in "off mode": even the JTAG logic including ICEPick is off in such a state, except for a mechanism called "ICEMelter" which notices when TRSTn is deasserted and TCK is clocked, which triggers it to power up the JTAG logic, and the debugger can then selectively re-enable power/clocks to other parts of the chip as needed to inspect things.

  • 0 in reply to Matthijs van Duin
    Prodigy 145 points

    Matthijs van Duin said:

    It should be, as long as you mind the annoying restriction that the control module disallows unprivileged writes.

    Yep, you are right, I could write from privileged mode, it appears to be doing what I want... fantastic! :-)

    I can still reset from JTAG with this set though, but I'm assuming reset is special and there is no way to access the core CPU/memory without doing a hard reset.

    Again, thank you for your help! :-D

    Just as a side note, how did you know about "CTRL_SEC_TAP_CTRL" ? It doesn't seem to be referenced anywhere publicly? I'm mostly just curious so I could figure things like this out myself! :-)