Can't debug Atom E3845 due to JTAG security

[William_N_1]

Hello,

We recently started using the Intel JTAG XDP probe with Atom E38xx processors using Coreboot and the Intel FSP.  On a BakerSport board the probe connects OK, but on our new board with an E3845 processor we get the following error message:

JTAG connection was established but the target appears to have security-restricted JTAG.  Please try disabling JTAG security in the platform firmware.

Searching the Intel docs and this forum haven't helped us figure out how to resolve this.  All I found was in the JTAG debugger release notes:

9.1.4  Platform security policy may inhibit debugger operation

In some platforms the security policy may disable JTAG access to the CPU, this is intended to prevent reverse-engineering.  In this case the JTAG debugger will successfully connect to the target, however it will not be able to discover any CPUs on the JTAG bus, and will warn the user that no CPUs are available.  To resolve this issue please ensure that that platform firmware has enabled access to the CPUs via JTAG, this is typically done by flashing a special “debug” firmware into the target.  

Also note that in some cases the CPU or CPU module may have physically disabled JTAG access, especially in production or near-production versions.  In this case please work with the platform business unit to obtain JTAG-enabled hardware.  

How do we get a firmware setup which will allow us to use the JTAG probe with our new board, please?

Thanks,

Bill

[Sukruth_H_Intel]

Hi Bill,

          Do you see any option in your BIOS settings to enable JTAG access? In the meanwhile I would also discuss with our team as whether FSP has some options to enable JTAG access.

Regards,
Sukruth H V

[William_N_1]

We're using coreboot/U-boot for our BIOS, and don't see any settings in coreboot or SOC straps to enable JTAG access.  Since this error only occurs on our new E3845 target and the same BIOS image runs correctly on our BakerSport evaluation board, can a BIOS setting be the problem?

Also, last night we verified the BIOS flash is correctly programmed and put a logic analyzer on the BIOS flash SPI signals.  We see:

• the CPU reads the Descriptor region correctly (descriptor map, component section, and SOC straps).
• we don't see any attempt to read the TXE region of the flash
• when the CPU attempts to read the opcodes at the reset vector, the MISO data line seems to be stuck high.

Are you aware of any hardware reason for this type of behavior?  Might it explain the "JTAG security error"?

Best regards,

Bill

[William_N_1]

Please ignore my last comment about the SPI not working correctly.  We found that disabling "high speed reads" allowed the SPI flash to be read correctly, and our board now starts running Coreboot.

We still can't debug with the emulator however; we get the same error message about JTAG security.

Best regards,

Bill

[Sukruth_H_Intel]

Hi Bill,

           Are you aware of any hardware reason for this type of behavior?  Might it explain the "JTAG security error"?

I am not aware of any hardware reasons, I have no idea on this. However I have requested my engineering team for possible reasons for this JTAG security error. I would update you as soon as I get the reply from them.

Regards,
Sukruth HV

[William_N_1]

Thanks for your reply, Sukruth.  As I mentioned earlier, the SPI interface is not the reason for the JTAG security error.  I did find that the eval board (where JTAG works) has an E3827 core while our board (where it doesn't) has an E3845 core, if that makes any difference.

Here's the exact error message we see in the debugger window when trying to connect to the E3845:

INFO: Initializing Target Connection Interface...
ERROR: Processor is not accessible for debug (CPU taps cannot be accessed due to platform policy). Please contact customer support.
ERROR: E-2201: JTAG connection was established but the target appears to have security-restricted JTAG.
Please try disabling JTAG security in the platform firmware.
ERROR: Unable to initialize Target Connection Interface

Maybe the "E-2201" error number will be helpful.

Also, I found what appears to be a bug in the FSP GOLD 3 distribution files from Intel: the definition of _VPD_DATA_REGION ("VLYVIEW1") in fspvpd.h doesn't match the structure defined in the BayleyBayFsp.bsf file.  It would be nice to know which is correct.

Unless we manage to figure this out, we will wait to hear from you.

Best regards,

Bill

[ZACHARY_G_Intel]

Bill,
I work on the JTAG debugger development team and I can try to help you with this...

As you saw in the release notes, some platforms specifically disable JTAG access to the CPU.  The message that you are seeing means that we have a successful connection to the target and can talk to the SOC, and we have specifically checked a "access allowed bit" to see if CPU access will be possible...  In other words this is not just some general error but rather a confirmation by the debugger that access is locked out.

Unfortunately on the JTAG team we are not experts in all CPU/SOC/board configurations, but in general this could be as simple as a firmware setting or board strapping, or it could be that JTAG access on this particular CPU SKU is fundamentally disabled.  In either case we probably can not do anything directly from the debugger side without more support from the Intel platform team.

It would be most effective if we can work with the Intel team that originated the CPU and/or platform design, do you have any contacts with them?  If you do please have them contact me directly and I will work with them to get more specific answers.  If you don't have a specific contact then we can still look into this, but it will take time to find the relevant folks (Intel is a big company!)

Thanks,
Zach

[William_N_1]

Thanks very much for your reply, Zach.

Unfortunately I don't have any contacts at Intel at all.

While we can't debug on our new board with the E3845, the exact same software (BIOS, TXE, microcode, and FSP) runs on the Intel Atom CRB with the E3827, and JTAG works there.  That seemed eliminate SOC straps and firmware settings as a source of the problem.

But thanks very much for your comment about board straps - it caused me to check the schematic for the CRB, and I found a jumper that allows JTAG debugging.  Unfortunately the signal goes to a microcontroller on the board and we have no idea what's done in there with it.  We're looking at the Intel Bakersport CRB schematic (524767_524767_Bakersport_FabB_r1p5.pdf); and found the jumper along with the text "enable jtag debug".  Can you find someone familiar with the microcontroller or CRB to ask?

Best regards,

Bill

[ZACHARY_G_Intel]

Bill,
The jumper could be for the CPU, or it could be for JTAG debug of some other microcontroller on the board, we will need to look into this.

We will look into this on our side and see what we can find out about your board and CPU, this may take a few days.  I will have one of our support folks contact you for followup.

  -Zach

[William_N_1]

Thanks, Zach.

Our management is frustrated with my lack of progress with this board, and would like to know if there are any options for raising the priority of our request and/or obtaining onsite support.

Best regards,

Bill

[Yessine_D_]

Hello

I have the same error with my MinnowBoard Max.

I tested coreboot on minnowmax and it works but unfortunately i can't debug with Jtag .

Is there a solution ? Is there a C code or  assembly code to initialize jtag ?

Thanks

[Aulia_R_]

thanks for posting. This is very helpful.