05-23-2019 09:42 AM - edited 05-23-2019 09:45 AM
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.
1 PS TAP
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?
05-24-2019 02:24 PM
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.
05-24-2019 03:57 PM
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.