Hardware assisted watchpoints not working

[tike64]

Hi,

My first attempt to get help on this issue was marked as spam. Don't know why. Submitting an abuse report did result in nothing. Anyway, here is my original text:

I have two i.MX6 designs at hand, dual and dual-plus. I have managed to get HW WP working on the dual (only occasionally) but never on dual-plus. I have narrowed the problem into SPNIDdis and SPIDdis bits in DBGDSCR register (I believe SPIDdis is irrelevant but it seems to go always hand in hand with SPNIDdis). When they are low, WPs work.

In dual the bits seems to be high always after power on. They will go zero after several U-Boot reset command and WPs start working. In dual-plus I have not yet seen them low and WPs have never worked.

I coded a little standalone program for U-Boot with which I check several registers and fuses: DBGAUTHSTATUS, DBGDSCR int and ext, DBGDEVID, DBGDIDR, DBGOSLSR, DBGPRSR GPR10, SRC_SCR, SBMR1, SBMR2 and all fuse shadow registers. DBGAUTHSTATUS shows 0xFF in working case and 0xAF in the nonworking case. I have seen no other differences in register contents.

I have tried to write 0x3A5331AA into DBGOSLAR, 0x03000002 into DBGDSCRext, 0x1E0520 into SRC_SCR, 0x1800 into GPR10. Nothing changes anything.

What am I missing? What should I try next?

Timo

[Rita_Wang]

DBGAUTHSTATUS shows 0xFF in working case and 0xAF in the nonworking case. I have seen no other differences in register contents.

A: For the The DBGAUTHSTATUS register in ARMv7 is usually read-only, and its value is set by hardware during chip manufacturing or initialization to reflect the status of debugging authorization. That is to say, this register is generally not allowed to be directly modified by software during runtime. If the current display is 0xAF, then this value is determined by hardware security mechanisms and cannot be changed through simple software.

So when you tried to write 0x3A5331AA into DBGOSLAR, 0x03000002 into DBGDSCRext, 0x1E0520 into SRC_SCR, 0x1800 into GPR10. Nothing changes.

DBGAUTHSTATUS | Jon's Arm Reference

[tike64]

On Dual Plus I'm seeing DBGAUTHSTATUS always as 0xAF, that is debugging disabled. If software can't change this, then the issue must be on hardware side. What hardware conditions are needed to enable debug?

[Rita_Wang]

Maybe you can not enable it, for the i.MX6Dula and i.MX6DUAL Plus they are different product.

It is basically impossible to change the value of DBGAUTHSTATUS from 0xAF to 0xFF in normal usage and design mode. If different debugging authorization behaviors are required, they can usually only be done by changing the chip's configuration at design time or using special debugging interfaces provided by the manufacturer, rather than dynamically modifying this register at runtime. In our side, we do not have this interfaces for customer to use.

[tike64]

So, do I understand correctly that on Dual Plus NXP has disabled debugging permanently?

How is it then possible that on Dual this sometimes works and sometimes not?

[Rita_Wang]

So, do I understand correctly that on Dual Plus NXP has disabled debugging permanently?

A:Yes, your understanding is right.  

How is it then possible that on Dual this sometimes works and sometimes not?

A: So sorry that I can not explain it well.

[tike64]

Is there anyone out there who is using this feature successfully?

Timo

[Rita_Wang]

Which version BSP are you using? For the WPs, what do you mean to , how can we reproduce your questions in our side?

[tike64]

Hi,

Thanks for looking at this.

My setup is based on BuildRoot 2021.08.2, vanilla Linux 5.4.78 and U-Boot imx_v2018.03_4.14.78_1.0.0_ga (7ade5b407fe6164c). By WP I mean hardware assisted watchpoints in gdb.

To reproduce, you can build a little test program:

unsigned u;

int main(int argc, char *argv[]) {
	u = argc;
	return 0;
}

 Then:

# gdb ./test-wp
GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-buildroot-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./test-wp...
(gdb) watch u
Hardware watchpoint 1: u
(gdb) info b
Num     Type           Disp Enb Address    What
1       hw watchpoint  keep y              u
(gdb) run
Starting program: /home/exertus/test-wp 

Watchpoint 1: u

Old value = 0
New value = 1
main (argc=1, argv=0xbe9c2d64) at test-wp.c:5
5       test-wp.c: No such file or directory.
(gdb) info b
Num     Type           Disp Enb Address    What
1       watchpoint     keep y              u
        breakpoint already hit 1 time
(gdb) 

Here gdb says setting HW WP and 'info b' confirms that. But when the program is run, it takes a long time and the second 'info b'  confirms that the WP had fallen back to soft WP. For a larger program this makes it impossible to use WPs.

Is this something that is supposed to work?

Timo

[Rita_Wang]

You mean dual work and dual-plus do not work?

[tike64]

Dual Plus does not work at all. Dual might work sometimes after several power on or reset cycles.

Timo

[Rita_Wang]

For these two board, using are most the same, so it is strange to run the same code with different test result. Here if you do not run the WPs, can these board work and run well?

[tike64]

Board designs are different. Therefore there is differences in the code too (mostly DTB and board adaptation code in U-Boot). As I wrote in my first message, the relevant bits are in prohibitive state already while looking them up in U-Boot. This makes me suspect our HW design or U-Boot but I can't find anything relevant in either.

Otherwise the boards are doing well.

Does this feature normally work on e.g. NXP evaluation boards?

Timo