We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 
Visitor unixboy
Registered: ‎07-31-2018

Ultrascale+ JTAG connection error in PMU FW

Hi all,

Hooking up Programmable JTAG device to Ultrasacle+ targets and tries to browse the list of cores with a command "targets", I met the following error message. I think it should go wrong.

xsct% targets
3 PL
5 PSU (JTAG port open error. AP transaction error, DAP status 30000021)
7 Cortex-R5 #0 (Halted)
8 Cortex-R5 #1 (Lock Step Mode)
10 Cortex-A53 #0 (APB AP transaction error, DAP status 30000021)
11 Cortex-A53 #1 (APB AP transaction error, DAP status 30000021)

Actually, "JTAG port open error" strikes me to kick up this issue in public to get any of more tips/ways to safely attack to. JTAG device was plugged into the target board in the middle of "normal working mode" not "JTAG booting mode". Some people in our company told me that it was how Xilinx guys does make remote on-line support through JTAG device. Actually not sure it is an usual way of JTAG mode support. **

PMU firmware had been loaded in "debug mode" not "release mode". Did you guys agree to a possibility of abnormal working due to this compilation strategy? When I found this error "XPFW: DAP RPU WAKE.. Done" message came out in UART console. I didn't activate RPU (R5 core) and nothing was loaded up into RPU domain. I didn't care RPU. **


"Gpi1Handler" in PMU FW was invoked as well. What is Gpi1 Interrupt? Anybody can explain to me what it is?

0 Kudos
2 Replies
Xilinx Employee
Xilinx Employee
Registered: ‎10-11-2011

Re: Ultrascale+ JTAG connection error in PMU FW

What's running on APU? Linux?

It does look like the APU are not accessible.

Does it work if you boot in JTAG boot mode? At least you can check the integrity of the JTAG chain in that way.

0 Kudos
Visitor unixboy
Registered: ‎07-31-2018

Re: Ultrascale+ JTAG connection error in PMU FW

Thanks Deny. 


Like your guess, I am now using Linux kernel 4.14.0- on Xilinx github site and I found that this issue had been strictly related with PMU FW in embeddedsw release in Xilinx github and Linux kernel booting. The main job of PMU(P = Platform) FW is the power management and this detail is now simply described as "turning off control blocks inside of Ultrascale in no use". Yes, the following is the footstep of kernel booting on ZCU102 ES2 board to comply with such a mission.  


[ 0.428633] mmc0: SDHCI controller on ff170000.sdhci [ff170000.sdhci] using ADMA 64-bit
[ 0.429833] hctosys: unable to open rtc device (rtc0)
[ 0.430464] of_cfs_init
[ 0.430800] of_cfs_init: OK
PMUFW: PmMmioWrite: (NODE_APU) ERROR: access denied for address 0xFD1A007C
[ 0.431625] PLL: shutdown
PMUFW: PmMmioWrite: (NODE_APU) ERROR: access denied for address 0xFF5E00A0
PMUFW: PmMmioWrite: (NODE_APU) ERROR: access denied for address 0xFF5E00B0
PMUFW: PmMmioWrite: (? 0.435550] RAMDISK: cramfs filesystem found at block 0
[ 0.436223] RAMDISK: Loading 9884KiB [1 disk] into ram disk... \
[ 0.481363] /
[ 0.496408] mmc0: new high speed SDHC card at address e624
[ 0.499899] \
[ 0.500883] mmcblk0: mmc0:e624 SB16G 14.8 GiB
[ 0.500949] \
[ 0.504091] mmcblk0: p1 p2
[ 0.504130] /
[ 0.509932] done.
[ 0.511803] VFS: Mounted root (cramfs filesystem) readonly on device 1:0.
[ 0.512697] devtmpfs: mounted
[ 0.517340] Freeing unused kernel memory: 10240K


PMU firmware actively reacts to the resuqest from kernel turning off block powers, by accessing 0xFD1A007C , 0xFF5E00A0, and 0xFF5E00B0 which are  DP_STC_REF_CTRL, CSU_PLL_CTRL and DBG_LPD_CTRL. The DBG_LPD_CTRL is related to JTAG activation and unfortunately I had changed the source code of PMU FW to gracefully match with the register access coverage maintained by kernel and the range of register access address permittable in PMU firmware. DBG_LPD_CTRL had been included in the range of control from the request of kernel. I changed it back to the original, made it out of access from the kernel by touching a file "pm_mmio_access.c" in PMU firmware.

Now JTAG can take an access to Ultrascale APU access in the middle of normal NAND/SD booting mode not in JTAG mode. It had inherently been supportable by using original materials of Xilinx release, but my source touch was the guility to break this fancy feature. 


Thanks for your reply, Denist. 



0 Kudos