Jetson AGX SMMU error with JTAG

I am trying to debug a LINUX kernel driver that is using physical memory that was set aside in the Device Tree. I can see everything working in the kernel driver but want to use a debugger (Lauterbach JTAG in my case) to read from 0x8600_0000 but it complains about the SMMU in the serial terminal view. The registers in the lower memory region read just fine but trying to read anything above 0x80000000 reports the error.

So my question is, how do I enable visibility through JTAG for the 0x86000000 memory region?

Hi

Can you share what change you have made.
And are you able to access the memory you want to using devmem2 ?

Also please note that, Xavier onwards, default support for debugger is Dstream.

thanks
Bibek

Using 4.5.1 SDK

Because devmem2 is trying to use /dev/mem it requires ‘sudo devmem2 0x86000000 w 0xabba’ and it works as expected.

I tried with and without a modified Device Tree to set aside a memory region to use an external device over JTAG to access this memory area. Both failed.

The modified device tree has 3 new entries
my_memreserve: /memreserve/ 0x0000000086000000 0x0000000000200000;
.
.
.
my_device {
compatible = “test,my_device”;
memory-region = <&my_reserve>;
};
.
.
.
my_reserve: my_reserve@86000000 {
//compatible = “shared-dma-pool”;
compatible = “test,my_device”;
reg = <0 0x86000000 0 0x200000>;
no-map; // if set, /dev/mem cannot write it
linux,phandle = <0x1e2>; //Use next available ID
phandle = <0x1e2>;
};

From a running program the device tree works as expected.

The errors that appear in the serial terminal during a debugger read while system is running are:
[ 1038.576720] t19x-arm-smmu 12000000.iommu: SMMU0: Unexpected {global,context} fault, this could be serious
[ 1038.576965] t19x-arm-smmu 12000000.iommu: GFSR 0x00000002, GFSYNR0 0x00000000, GFSYNR1 0x00000000, GFSYNR2 0x00000000, fault_addr=0x86000000, sid=0(0x0 - Unassigned SID)
[ 1038.577486] t19x-arm-smmu 12000000.iommu: SMMU0: Unexpected {global,context} fault, this could be serious
[ 1038.577670] t19x-arm-smmu 12000000.iommu: GFSR 0x80000000, GFSYNR0 0x00000000, GFSYNR1 0x00000000, GFSYNR2 0x00000000, fault_addr=0x86000000, sid=0(0x0 - Unassigned SID)
[ 1038.578154] t19x-arm-smmu 12000000.iommu: SMMU0: Unexpected {global,context} fault, this could be serious
[ 1038.578325] t19x-arm-smmu 12000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000000, GFSYNR1 0x00000000, GFSYNR2 0x00000000, fault_addr=0x86000000, sid=0(0x0 - Unassigned SID)
[ 1038.578809] t19x-arm-smmu 12000000.iommu: SMMU0: Unexpected {global,context} fault, this could be serious
[ 1038.579091] t19x-arm-smmu 12000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000000, GFSYNR1 0x00000000, GFSYNR2 0x00000000, fault_addr=0x86000000, sid=0(0x0 - Unassigned SID)
[ 1038.585274] mc-err: (255) csr_axiapr: EMEM address decode error
[ 1038.591233] mc-err: status = 0x20064082; addr = 0xffffffff00; hi_adr_reg=ff08
[ 1038.598578] mc-err: secure: yes, access-type: read

what is this driver trying to do?

The driver is an interface between an external tool and the running application.

As I have had more time on this now, I no longer think the kernel driver is an issue. If I ‘halt’ the processor I can read memory at the physical address just fine with the debugger without errors. If however the processor is running while it tries to access the physical RAM the errors occur. So I believe that it is a setting in the SDK that may need to be tweaked to allow JTAG access while running.

Still looking but have not been able to find what I need yet.

Can you refer “/sys/kernel/debug/memblock/reserved” node to confirm if the range is reserved successfully (or) use an unused range.

nvidia@JetsonNoUsb:~$ sudo cat /sys/kernel/debug/memblock/reserved
[sudo] password for nvidia:
0: 0x0000000080000000…0x000000008000ffff
1: 0x0000000080080000…0x0000000082200fff
2: 0x0000000082202000…0x0000000082202fff
3: 0x0000000086000000…0x00000000861fffff
.
.
.

So it is set aside. Referencing a section of RAM that is not reserved gives the same error messages.

Could you explain more about the steps you follow when you get error on accessing physical RAM when the processor is running. Usually, we stop and then read the data.
Have you tried the same steps on any other SOC and the worked?

I have done it on others like the Qualcomm sa8155 running QNX. But not on another processor running LINUX.

Steps

  1. use “attach” in Lauterbach when the processor is running.
  2. Bring up a data.dump 0x86000000 /dialog
  3. bring up a serial terminal on the Jetson
  4. select “E” on the dialog to read the memory live.
  5. Error messages start to happen in the serial terminal

It has to be able to push and pull data while it is running since it is a mailbox.