Enabling DBGEN signal in GP OMAP3

Enabling DBGEN signal in GP OMAP3

[Grazvydas Ignotas]

Hi,

Does anyone know if there is a way to make DBGEN signal high on
OMAP3530 and/or DM3730 without using a hardware debugger? My goal is
to make use of hardware watchpoints in Cortex-A8, but that requires
DBGEN to be high.

The TRM states:
"The DBGEM signal on the Cortex-A8 is driven by setting bit 13 at
address 0x5401 D030 in the DAP-APB address space."
However regardless of how hard I try the writes to that register seem
to be ignored. I even tried to do it from IVA/C64x with no success.
(I assume DBGEM is a typo since Cortex-A8 manuals have no mention of
it, and they meant DBGEN there).

It seems others had this problem too, and TI is as helpful as ever:
http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/30011/104527

DBGEN is mentioned by Will Deacon's commit
8954bb0da99b76c7ce5edf2f314807cff68b6ea8 , but I guess he mixed NIDEN
with DBGEN there (DBGAUTHSTATUS returns 0x000000ae so NIDEN is indeed
set here, and I have tried old kernel where OMAP3_EMU was still
available).

0x5401D030 is referenced by some OpenOCD scripts, so I guess it's
writeable over jtag, but not by the CPU(s). It's quite a mysterious
otherwise undocumented register, I've noticed it's bit21 is some
status bit related to Cortex-A8's low power states.


Gražvydas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Enabling DBGEN signal in GP OMAP3

[Tony Lindgren]

* Grazvydas Ignotas <notasas@gmail.com> [150215 13:34]:
> Hi,
> 
> Does anyone know if there is a way to make DBGEN signal high on
> OMAP3530 and/or DM3730 without using a hardware debugger? My goal is
> to make use of hardware watchpoints in Cortex-A8, but that requires
> DBGEN to be high.
> 
> The TRM states:
> "The DBGEM signal on the Cortex-A8 is driven by setting bit 13 at
> address 0x5401 D030 in the DAP-APB address space."
> However regardless of how hard I try the writes to that register seem
> to be ignored. I even tried to do it from IVA/C64x with no success.
> (I assume DBGEM is a typo since Cortex-A8 manuals have no mention of
> it, and they meant DBGEN there).
> 
> It seems others had this problem too, and TI is as helpful as ever:
> http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/30011/104527
> 
> DBGEN is mentioned by Will Deacon's commit
> 8954bb0da99b76c7ce5edf2f314807cff68b6ea8 , but I guess he mixed NIDEN
> with DBGEN there (DBGAUTHSTATUS returns 0x000000ae so NIDEN is indeed
> set here, and I have tried old kernel where OMAP3_EMU was still
> available).

Does the perf counter still work OK? Looks like OMAP3_EMU got
removed by commit 184901a06a36 ("ARM: removing support for etb/etm in
"arch/arm/kernel/"").

The perf counter on omap3 used to work, but is buggy at least on
3430 because it eventually stops producing interrupts because of
some bug in the Cortex-A8 version being used.

Looking at the commits it seems that it probably only works for
device tree based booting nowadays.

Also, it seems that having the etm@54010000, etb@540000000
and etb@5401b000 entries only in the omap3-beagle*.dts files
is wrong. To me it seems they should be in the omap3.dtsi and
omap36xx.dtsi instead. Looks like those got added by commit
9d31620268a7 ("coresight: adding support for beagle and beagleXM").

So maybe moving  the etb and etm entries to omap3.dtsi and
omap36xx.dtsi is all you need with the current mainline kernel?
 
> 0x5401D030 is referenced by some OpenOCD scripts, so I guess it's
> writeable over jtag, but not by the CPU(s). It's quite a mysterious
> otherwise undocumented register, I've noticed it's bit21 is some
> status bit related to Cortex-A8's low power states.

Have you checked the Cortex-A8 documentation for the debugger?
It seems that's where they should be documented.

Regards,

Tony

Re: Enabling DBGEN signal in GP OMAP3

[Matthijs van Duin]

I don't have an OMAP3 to play with, but I wouldn't be surprised if a
debug-enable bit also needs to be set in an ICEPick control register.
On omap4-generation targets with ICEPick-D (e.g. dm81xx and am335x)
the DBGEN signal is in fact fully controlled via ICEPick.

This really sucks since without it you can't use debug monitor
functionality such as hardware breakpoints and watchpoints, or have an
aux core (e.g. a cortex-m3) perform halting debug on the main core.
I've actually considered asking for a hardware patch on our board to
allow it to self-jtag via gpio just to enable that stupid bit
(basically everything else is memory-mapped).

(As a random note, on the am335x the JTAG pins have pinconf registers,
in that case it may suffice to externally pull/drive all pins up and
then toggle the RXEN bit in software, given that even the (warm) reset
pin responds to such manipulation.)

Re: Enabling DBGEN signal in GP OMAP3

[Matthijs van Duin]

On 15 February 2015 at 22:30, Grazvydas Ignotas <notasas@gmail.com> wrote:
> "The DBGEM signal on the Cortex-A8 is driven by setting bit 13 at
> address 0x5401 D030 in the DAP-APB address space."

The register is apparently, for some reason, called DAP_PC_FER
according to some notes of mine (I have no idea anymore where I got
these from) listing a few DAPCTL registers:

//      dap_pc_fer      APB     0xd401d030      ;DAP_PC for Cortex-A8
//      dap_pc_ime      APB     0xd401d034      ;DAP_PC for IME
//      dap_pc_ilf      APB     0xd401d038      ;DAP_PC for ILF
//      dap_pc_vlc      APB     0xd401d03c      ;DAP_PC for VLC
//      dap_pc_core     APB     0xd401d040      ;DAP_PC for Core


> However regardless of how hard I try the writes to that register seem
> to be ignored.

Just checking... it's possible of course that DAPCTL tries to be
coresight-compatible and has a lock_access register at 0x5401dfb0 to
which you need to write 0xc5acces5. To be safe you can first check
whether 0x5401dfb4 (lock_status) reads 3 before doing so (and it
should then become 1). Debuggers generally don't need to worry about
it since access via APB-AP (with bit 31 / MReqDebug set) bypasses such
locks.

A dump of all non-zero registers in DAPCTL (the 4KB block at
0x5401d000) might be interesting.

> It seems others had this problem too, and TI is as helpful as ever:
> http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/30011/104527

(The reply post is weird though, since you don't need DBGEN for
performance counters, but I'm not gonna bump a thread from 2009)

> 0x5401D030 is referenced by some OpenOCD scripts, so I guess it's
> writeable over jtag, but not by the CPU(s).

If a write is done to that address as-is (via either AHB-AP or
APB-AP), rather than an APB-AP write with bit 31 set, then I think you
should be able to write it from the processor too.  If so, it means
access is unlocked by some previous step such as my main worry, bit 13
(DEBUGENABLE) of ICEPick debug tap 3 control.

You can try writing it from the cortex-a8 while a debugger is
connected (if using CCS you can connect to DAP without connecting to
the Cortex-A8, in which case it shouldn't get confused if you mess
with DBGEN. OpenOCD doesn't support this afaik so it'll probably get
confused... well so be it)

If you have an FTDI-based debugger (preferably an XDS100v2) I can
provide a little test tool to directly manipulate ICEPick registers to
futher test this theory. (Alternatively, driving nTRST high and
bit-banging TMS and TDI can do the job too, the sequence isn't very
long I think)

> It's quite a mysterious otherwise undocumented register

Debug and crypto are two areas where the (otherwise usually quite
good) public documentation of TI SoCs is unfortunately sorely lacking.
This is a shame, since both are useful in nearly all application
domains. My guess is that these two subjects are secretive since info
about them (shouldn't but) might help people copy netflix films off
their smartphone or whatever. Perhaps now that omapgeddon has come to
pass they might open up on these topics, but that may just be wishful
thinking.

Fortunately info about these subsystems leaks out of TI all over the
place, but scraping bits and pieces from many sources together and
filling in the blanks with empirical science takes more time than one
ought to have to spend on it.



On 16 February 2015 at 18:58, Tony Lindgren <tony@atomide.com> wrote:
> The perf counter on omap3 used to work, but is buggy at least on
> 3430 because it eventually stops producing interrupts because of
> some bug in the Cortex-A8 version being used.

Of course the workaround of polling the counters at least once per
2^31 clock cycles to detect when they wrap (or in general keep local
64-bit copies up-to-date) is not really a huge burden.


>> 0x5401D030 is referenced by some OpenOCD scripts, so I guess it's
>> writeable over jtag, but not by the CPU(s). It's quite a mysterious
>> otherwise undocumented register, I've noticed it's bit21 is some
>> status bit related to Cortex-A8's low power states.
>
> Have you checked the Cortex-A8 documentation for the debugger?
> It seems that's where they should be documented.

DAPCTL is a TI-specific debug peripheral, it's not from ARM or related
to the Cortex-A8 specifically.

Re: Enabling DBGEN signal in GP OMAP3

[Grazvydas Ignotas]

[-- Attachment #1: Type: text/plain, Size: 4941 bytes --]

On Mon, Feb 16, 2015 at 8:43 PM, Matthijs van Duin
<matthijsvanduin@gmail.com> wrote:
>
> This really sucks since without it you can't use debug monitor
> functionality such as hardware breakpoints and watchpoints, or have an
> aux core (e.g. a cortex-m3) perform halting debug on the main core.
> I've actually considered asking for a hardware patch on our board to
> allow it to self-jtag via gpio just to enable that stupid bit
> (basically everything else is memory-mapped).

I absolutely agree.

> (As a random note, on the am335x the JTAG pins have pinconf registers,
> in that case it may suffice to externally pull/drive all pins up and
> then toggle the RXEN bit in software, given that even the (warm) reset
> pin responds to such manipulation.)

DM3730 (equivalent to OMAP3630) that I'm using also has pinconf
registers on all JTAG pins, and there are external pullups on my
board. So I guess you mean performing I/O by quickly
enabling/disabling the pulldowns? Would that satisfy any timing
requirements? I doubt pinmux register access would be fast from the
CPU (OMAP3 is known not to be a good GPIO bitbanger even).

And what is RXEN bit? I can't find it referenced anywhere (and I'll
admit I don't have experience with hardware debuggers).

On Mon, Feb 16, 2015 at 10:09 PM, Matthijs van Duin
<matthijsvanduin@gmail.com> wrote:
> On 15 February 2015 at 22:30, Grazvydas Ignotas <notasas@gmail.com> wrote:
>> "The DBGEM signal on the Cortex-A8 is driven by setting bit 13 at
>> address 0x5401 D030 in the DAP-APB address space."
>
> The register is apparently, for some reason, called DAP_PC_FER
> according to some notes of mine (I have no idea anymore where I got
> these from) listing a few DAPCTL registers:
>
> //      dap_pc_fer      APB     0xd401d030      ;DAP_PC for Cortex-A8
> //      dap_pc_ime      APB     0xd401d034      ;DAP_PC for IME
> //      dap_pc_ilf      APB     0xd401d038      ;DAP_PC for ILF
> //      dap_pc_vlc      APB     0xd401d03c      ;DAP_PC for VLC
> //      dap_pc_core     APB     0xd401d040      ;DAP_PC for Core

Interesting.

>> However regardless of how hard I try the writes to that register seem
>> to be ignored.
>
> Just checking... it's possible of course that DAPCTL tries to be
> coresight-compatible and has a lock_access register at 0x5401dfb0 to
> which you need to write 0xc5acces5. To be safe you can first check
> whether 0x5401dfb4 (lock_status) reads 3 before doing so (and it
> should then become 1).

It doesn't seem to be, trying to access these registers (tried reading
and writing) results in data abort..

> Debuggers generally don't need to worry about
> it since access via APB-AP (with bit 31 / MReqDebug set) bypasses such
> locks.
>
> A dump of all non-zero registers in DAPCTL (the 4KB block at
> 0x5401d000) might be interesting.

Attached, fault means external data abort (or at least that's what
Linux kernel calls it).
Note that it was done with Linux kernel running, with chip low power
states enabled and everything.

>> It seems others had this problem too, and TI is as helpful as ever:
>> http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/30011/104527
>
> (The reply post is weird though, since you don't need DBGEN for
> performance counters, but I'm not gonna bump a thread from 2009)

Yes, the performance counters are working fine already.

>> 0x5401D030 is referenced by some OpenOCD scripts, so I guess it's
>> writeable over jtag, but not by the CPU(s).
>
> If a write is done to that address as-is (via either AHB-AP or
> APB-AP), rather than an APB-AP write with bit 31 set, then I think you
> should be able to write it from the processor too.  If so, it means
> access is unlocked by some previous step such as my main worry, bit 13
> (DEBUGENABLE) of ICEPick debug tap 3 control.
>
> You can try writing it from the cortex-a8 while a debugger is
> connected (if using CCS you can connect to DAP without connecting to
> the Cortex-A8, in which case it shouldn't get confused if you mess
> with DBGEN. OpenOCD doesn't support this afaik so it'll probably get
> confused... well so be it)
>
> If you have an FTDI-based debugger (preferably an XDS100v2) I can
> provide a little test tool to directly manipulate ICEPick registers to
> futher test this theory. (Alternatively, driving nTRST high and
> bit-banging TMS and TDI can do the job too, the sequence isn't very
> long I think)

Unfortunately I don't have any hardware debuggers.
I could try the bitbang method if you think it can work, although my
board (openpandora) has a 10K pulldown resistor on nTRST that I'm not
sure OMAP's internal pullup would win over. Is there any way to check
if anytihng works from the CPU?
Maybe I could modify my board, I could connect some spare GPIO pads to
jtag pads, but I don't know if it's even worth trying.


Gražvydas

[-- Attachment #2: dm3730_5401d000.txt --]
[-- Type: text/plain, Size: 554 bytes --]

5401d000 00000010
5401d004 fault
5401d008 fault
5401d00c fault
5401d010 00000000
5401d014 fault
...
5401d02c fault
5401d030 00200026
5401d034 00220002
5401d038 00220002
5401d03c 00220002
5401d040 00200024
5401d044 fault
5401d048 fault
5401d04c fault
5401d050 00000000
5401d054 00000000
5401d058 20000000
5401d05c fault
...
5401dfcc fault
5401dfd0 00000000
5401dfd4 00000000
5401dfd8 00000000
5401dfdc 00000000
5401dfe0 00000043
5401dfe4 00000073
5401dfe8 00000009
5401dfec 00000000
5401dff0 0000000d
5401dff4 000000f0
5401dff8 00000005
5401dffc 000000b1

Re: Enabling DBGEN signal in GP OMAP3

[Matthijs van Duin]

On 18 February 2015 at 00:37, Grazvydas Ignotas wrote:
> On Mon, Feb 16, 2015 at 8:43 PM, Matthijs van Duin wrote:
>> A dump of all non-zero registers in DAPCTL (the 4KB block at
>> 0x5401d000) might be interesting.
>
> Attached

OK, nice.  I like peripherals which fault accesses to non-existent (or
at least non-readable) regs, makes it easier to make an inventory of
what's there :-)   So, we have some standard ID regs at the end:
CID = b1 05 f0 0d -- PrimeCell or system peripheral (i.e. not coresight)
PID = 00 00 09 73 43 -- vendor 0x097 (TI), part 0x343, rev 0x00
and indeed no other coresight management regs. The partcode 0x343
might be a reference to the omap3430. Regs at 000 and 010 presumably
revision and sysconfig.

030-040 are the core debug control regs... in fact, judging by their
values and the fact you mentioned bit 13 controls DBGEN, these regs
look very much like the ICEPick-D core debug control regs, which
themselves are simplified versions of debug TAP control registers (for
which you can find the layout in the dm3730 TRM's debug chapter).

050 and 054 are unknown, but 058 reads 0x20000000 which suggests it
may have an ownership claim command register there. Try writing
0x40000000 to it, if that succeeds and it reads back 0x70000000 then
you're successfully claimed ownership which hopefully means you can
then write to other regs too, although they may not take effect unless
you enable the module by writing 0x80000000 to the ownership claim
command register, after which it should read back 0xb0000000. Of
course it's also possible it only covers registers 050 and 054,
whatever they may be... (or it might be something else altogether)

If this doesn't work either, then bitbanging JTAG is plan B...


>> (As a random note, on the am335x the JTAG pins have pinconf registers,
>> in that case it may suffice to externally pull/drive all pins up and
>> then toggle the RXEN bit in software, given that even the (warm) reset
>> pin responds to such manipulation.)
>
> DM3730 (equivalent to OMAP3630) that I'm using also has pinconf
> registers on all JTAG pins, and there are external pullups on my
> board. So I guess you mean performing I/O by quickly
> enabling/disabling the pulldowns? Would that satisfy any timing
> requirements? I doubt pinmux register access would be fast from the
> CPU (OMAP3 is known not to be a good GPIO bitbanger even).
>
> And what is RXEN bit? I can't find it referenced anywhere (and I'll
> admit I don't have experience with hardware debuggers).

RXEN == INPUTENABLE

At least on the am335x, disabling it causes the processor to perceive
the input as being low regardless of its actual level. Since the line
itself doesn't have to change level, this can be toggled pretty fast
probably. Using this to simulate an input does require the actual line
level to be high obviously.

Using the pull up/down to toggle an IO can definitely also work, but
only if the pin is really floating since the internal pulls are really
weak afaik. They're not gonna win from that 10k resistor. And
obviously you then need to toggle it slow enough to allow the pull
resistor to do its job.

JTAG has no lower limit on clock speed, or any other timing
constraints other than minimum setup/hold/cycle times, so bitbanging
it using slow GPIO is no problem if you don't care about performance
but only need to set some debug enable bit.


> I could try the bitbang method if you think it can work, although my
> board (openpandora) has a 10K pulldown resistor on nTRST that I'm not
> sure OMAP's internal pullup would win over.

It won't, you'll need to externally drive it up, e.g. by connecting it
to the Vref pin that's also on the jtag connector.

> Is there any way to check if anything works from the CPU?
> Maybe I could modify my board, I could connect some spare GPIO pads to
> jtag pads, but I don't know if it's even worth trying.

If the ownership claim register doesn't work it may be worth a try, if
you're comfortable doing that. Connecting them to GPIOs will
definitely work, though just driving the inputs high and toggling
INPUTENABLE via padconf *may* also work and be simpler.

Pin summary:
nTRST - cpu input, must be high for JTAG to work
TCK - cpu input, clock, idle low
TMS - cpu input, command, captured on rising TCK edge
TDI - cpu input, data, captured on rising TCK edge during data xfer
TDO - cpu output, useful to capture so you're not working blind
RTCK - cpu output, optional to capture: it should follow TCK if all is well

It's essentially SPI mode 0, but with two MOSI signals (TMS and TDI)
and one MISO (TDO). RTCK is an acknowledge of TCK, and mostly relevant
when connecting to older (pre-Cortex) ARM cores since they
resynchronize TCK to their core clock (so if their clock can change,
e.g. due to power management, you need to watch RTCK to ensure you're
not going too fast).

See also http://e2e.ti.com/support/arm/sitara_arm/f/791/p/385704/1377250#1377250
for some diagrams and explanation (pictures always help).

Re: Enabling DBGEN signal in GP OMAP3

[Tony Lindgren]

* Matthijs van Duin <matthijsvanduin@gmail.com> [150216 12:12]:
> On 16 February 2015 at 18:58, Tony Lindgren <tony@atomide.com> wrote:
> > The perf counter on omap3 used to work, but is buggy at least on
> > 3430 because it eventually stops producing interrupts because of
> > some bug in the Cortex-A8 version being used.
> 
> Of course the workaround of polling the counters at least once per
> 2^31 clock cycles to detect when they wrap (or in general keep local
> 64-bit copies up-to-date) is not really a huge burden.

>From memory.. I believe the issue was that for anything needing to
set the counter and rely on the counter interrupt things would fail
as the counter interrupts would not always happen.

Regards,

Tony

Re: Enabling DBGEN signal in GP OMAP3

[Matthijs van Duin]

On 18 February 2015 at 15:54, Tony Lindgren <tony@atomide.com> wrote:
> From memory.. I believe the issue was that for anything needing to
> set the counter and rely on the counter interrupt things would fail
> as the counter interrupts would not always happen.

Correct, but the interrupt is just used to indicate when counters
overflow, intended to be used to correctly keep track of the counters
when they exceed 2^32 (which can happen easily when measuring across a
timespan of more than a few seconds).

However, no performance counter can increment more than twice per cpu
cycle, which means it takes at least 2^31 cpu cycles to completely
wrap a counter around.  If you make sure you update local copies
(untested code below) more often than once per 2^31 cycles they should
therefore keep accurate track.

void update_perf_counters( u64 ctr[4] )
{
        for( int i = 0; i < 4; i++ ) {
                u32 val;
                asm volatile( "mcr p15, 0, %0, c9, c12, 5" :: "r"(i) );
                asm volatile( "mrc p15, 0, %0, c9, c13, 2" : "=r"(val) );
                ctr[i] += (u32)( val - ctr[i] );
        }
}

- Matthijs

Re: Enabling DBGEN signal in GP OMAP3

[Tony Lindgren]

* Matthijs van Duin <matthijsvanduin@gmail.com> [150218 10:32]:
> On 18 February 2015 at 15:54, Tony Lindgren <tony@atomide.com> wrote:
> > From memory.. I believe the issue was that for anything needing to
> > set the counter and rely on the counter interrupt things would fail
> > as the counter interrupts would not always happen.
> 
> Correct, but the interrupt is just used to indicate when counters
> overflow, intended to be used to correctly keep track of the counters
> when they exceed 2^32 (which can happen easily when measuring across a
> timespan of more than a few seconds).
> 
> However, no performance counter can increment more than twice per cpu
> cycle, which means it takes at least 2^31 cpu cycles to completely
> wrap a counter around.  If you make sure you update local copies
> (untested code below) more often than once per 2^31 cycles they should
> therefore keep accurate track.
> 
> void update_perf_counters( u64 ctr[4] )
> {
>         for( int i = 0; i < 4; i++ ) {
>                 u32 val;
>                 asm volatile( "mcr p15, 0, %0, c9, c12, 5" :: "r"(i) );
>                 asm volatile( "mrc p15, 0, %0, c9, c13, 2" : "=r"(val) );
>                 ctr[i] += (u32)( val - ctr[i] );
>         }
> }

Hmm yeah maybe oprofile/perf whatever has maximum value that can be
specified for the counter length that allows working around it.

Regards,

Tony

Re: Enabling DBGEN signal in GP OMAP3

[Grazvydas Ignotas]

On Wed, Feb 18, 2015 at 5:00 AM, Matthijs van Duin
<matthijsvanduin@gmail.com> wrote:
>
> 030-040 are the core debug control regs... in fact, judging by their
> values and the fact you mentioned bit 13 controls DBGEN, these regs
> look very much like the ICEPick-D core debug control regs, which
> themselves are simplified versions of debug TAP control registers (for
> which you can find the layout in the dm3730 TRM's debug chapter).
>
> 050 and 054 are unknown, but 058 reads 0x20000000 which suggests it
> may have an ownership claim command register there. Try writing
> 0x40000000 to it, if that succeeds and it reads back 0x70000000 then
> you're successfully claimed ownership which hopefully means you can
> then write to other regs too, although they may not take effect unless
> you enable the module by writing 0x80000000 to the ownership claim
> command register, after which it should read back 0xb0000000. Of
> course it's also possible it only covers registers 050 and 054,
> whatever they may be... (or it might be something else altogether)

It turns out 050, 054 and 058 (but only them) are actually documented
in dm3730 manual and are part of Emulation Pin Manager. 058 works as
you (and the manual) describe, however claiming and enabling EPM
registers still doesn't enable writing to 030 :(

>
> RXEN == INPUTENABLE
>
> At least on the am335x, disabling it causes the processor to perceive
> the input as being low regardless of its actual level. Since the line
> itself doesn't have to change level, this can be toggled pretty fast
> probably. Using this to simulate an input does require the actual line
> level to be high obviously.

OK thanks for all the info. I've tested a spare floating pin by muxing
it as a GPIO on my dm3730 and it works as you describe, nice.
Hopefully this also applies to jtag pins there.

>> I could try the bitbang method if you think it can work, although my
>> board (openpandora) has a 10K pulldown resistor on nTRST that I'm not
>> sure OMAP's internal pullup would win over.
>
> It won't, you'll need to externally drive it up, e.g. by connecting it
> to the Vref pin that's also on the jtag connector.
>
>> Is there any way to check if anything works from the CPU?
>> Maybe I could modify my board, I could connect some spare GPIO pads to
>> jtag pads, but I don't know if it's even worth trying.
>
> If the ownership claim register doesn't work it may be worth a try, if
> you're comfortable doing that. Connecting them to GPIOs will
> definitely work, though just driving the inputs high and toggling
> INPUTENABLE via padconf *may* also work and be simpler.

Ok, sounds like I need to find and get rid of that 10k resistor, or
connect the pad to 1.8V. It's just a shame that there doesn't seem to
be a way to do it purely in software so that other pandora users could
have hardware watchpoints.

If you could share the programming sequence it would be great.

Thanks again,
Gražvydas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Enabling DBGEN signal in GP OMAP3

[Matthijs van Duin]

On 19 February 2015 at 03:16, Grazvydas Ignotas <notasas@gmail.com> wrote:
> It turns out 050, 054 and 058 (but only them) are actually documented
> in dm3730 manual and are part of Emulation Pin Manager. 058 works as
> you (and the manual) describe, however claiming and enabling EPM
> registers still doesn't enable writing to 030 :(

Ah, bummer.

> OK thanks for all the info. I've tested a spare floating pin by muxing
> it as a GPIO on my dm3730 and it works as you describe, nice.
> Hopefully this also applies to jtag pins there.

At least on the am335x disabling RXEN of the TMS pin rendered JTAG
inoperable, which means it looks like the technique will at least work
there.  I'm now working on a test to see if it really works.  Once
done it shouldn't be too hard to adapt to the dm37xx: the padconf
registers are different obviously, but the bitbang sequence will be
almost the same (just a different ICEPick register), at least if
setting debug-enable on DAP's tap control register suffices. If it
turns out you really need to write to the DAPCTL registers themselves
via JTAG, that will be a bit more work...

> Ok, sounds like I need to find and get rid of that 10k resistor, or
> connect the pad to 1.8V. It's just a shame that there doesn't seem to
> be a way to do it purely in software so that other pandora users could
> have hardware watchpoints.

You can solder-blob a path from nTRST to Vref via other input pads
(which all need to be high, but they should already be pulled up
anyway), as long as you avoid GND and the outputs (TDO and RTCK).
Though I'm not sure that's a good idea considering it looks like
there's a ground plane running between the pads...

Anyhow, I'm currently testing just with nTRST connected to Vref, and
TDO to some GPIO for monitoring.


> If you could share the programming sequence it would be great.

Working on it!

When you manage to get nTRST (and the other all relevant inputs: TMS,
TDI, TCK) high, you can first try simple tests:
(all this should be done by via INPUTENABLE of the pads):
1. nTRST low, TMS and TDI high, toggle TCK a bunch of times (at least
five rising edges) and end with TCK low.
2. nTRST high, TMS low, and start toggling TCK.  If all is well,
sooner or later (possible right away), the processor's RTCK output
should start following TCK.  If this is the case, then you can pretty
much start doing the victory-dance ;-)  When you stop toggling, make
sure you end with TCK low.
3. If you also want to see TDO in action, perform the following
sequence: TMS high, one TCK pulse (high-low), TMS low again, and start
toggling TCK: after two pulses the processor should start driving TDO
and the 32-bit JTAG ID should emerge from it, after which TDO remains
high. To exit data mode and return to idle state again, give two TCK
pulses with TMS high. TDO will go high-Z again (after the first TCK
pulse already in fact).
4. The final pin to test is TDI: repeat step 3, but occasionally
change TDI in between clock pulses. JTAG uses shift registers for
everything, so after outputting the 32-bit JTAG ID it will actually
start repeating the input you provided, but with 32 cycles delay. When
you exit data mode, the JTAG ID register will discard the data you
provided.

Re: Enabling DBGEN signal in GP OMAP3

[Matthijs van Duin]

At least on the am335x, the trick actually works!  I have a working
demo which configures ICEPick registers and even performs transactions
on the debug interconnect.

I've been lazy and imported a bunch of files from my baremetal
projects so I could easily mess with the hardware, rudely bypassing
the kernel.  The whole implementation is hideous in all sorts of ways,
but it gets the job done: https://github.com/dutchanddutch/jbang

The key part, how to bitbang JTAG, is reasonably isolated from all
this in src/jbang.cc and glues onto the device-specific part via
hw-subarctic.h.  You could probably also turn jbang.cc into plain C
without too much effort and discard the rest... I accept that my code
style is probably a bit of an acquired taste ;-)

For the omap3, apart from the differences in padconf details, you'll
want to change icepick_init_regs[] to just { 0x23002100 } I think and
hopefully you can then write the DAPCTL regs using ap_write().

I hope this example is of any help.

Matthijs

Re: Enabling DBGEN signal in GP OMAP3

[Grazvydas Ignotas]

[-- Attachment #1: Type: text/plain, Size: 2518 bytes --]

On Mon, Feb 23, 2015 at 1:52 PM, Matthijs van Duin
<matthijsvanduin@gmail.com> wrote:
> At least on the am335x, the trick actually works!  I have a working
> demo which configures ICEPick registers and even performs transactions
> on the debug interconnect.

Nice!

> I've been lazy and imported a bunch of files from my baremetal
> projects so I could easily mess with the hardware, rudely bypassing
> the kernel.  The whole implementation is hideous in all sorts of ways,
> but it gets the job done: https://github.com/dutchanddutch/jbang
>
> The key part, how to bitbang JTAG, is reasonably isolated from all
> this in src/jbang.cc and glues onto the device-specific part via
> hw-subarctic.h.  You could probably also turn jbang.cc into plain C
> without too much effort and discard the rest... I accept that my code
> style is probably a bit of an acquired taste ;-)
>
> For the omap3, apart from the differences in padconf details, you'll
> want to change icepick_init_regs[] to just { 0x23002100 } I think and
> hopefully you can then write the DAPCTL regs using ap_write().

I've finally got rid of nTRST pulldown (haven't connected TDO though),
created hw-omap3.{h,cc}, but couldn't get it to do anything, until it
came to my mind that you may be running ARM on your BBB slower that
1GHz that I'm using on my DM3730. So lowered the clock to 500MHz and
voila, it worked!

I guess I'll still connect TDO as it's not so much fun without it,
going to try connecting to EMU0 too, hopefully it doesn't mess up the
boot modes.

Before I could get it all to work a coworker lent me an Altera USB
Blaster, which I've connected to a pandora prototype board I still
have from a long time ago and wasn't that afraid to kill with bad
soldering job. And hey, it worked too with your code modified to use
USB Blaster in it's bitbang mode over libftdi. This setup also works
with openocd, but somewhat unreliably (only occasionally gets through
init, often gets register values it doesn't like).

My main goal is to have hardware watchpoints on the cased production
unit without extra hardware, and it looks like I can finally have
that, thanks!

> I hope this example is of any help.

It sure is! The only thing I do not understand is why are you using
that process_vm_readv() call, mmap() already makes unprivileged user
mode writable mappings.

Anyway I'm attaching my code too, feel free to incorporate it too
and/or ultra-modernize to your c++ dialect.

Gražvydas

[-- Attachment #2: hw-omap3.cc --]
[-- Type: text/x-c++src, Size: 1031 bytes --]

#include "defs.h"
#include "map-phys.h"
#include "hw-omap3.h"

static u16 *padconf_regs;

//-------------- JTAG pin i/o ------------------------------------------------//

// JTAG inputs controlled by toggling receiver-enable (pins must be pulled high
// externally or left floating to allow internal pull-up to work).
//
let static sim_input( uint offset, bool level )
{
	padconf_regs[offset >> 1] = 0x0018 | (level ? 0x0100 : 0x0000);
}

// JTAG inputs controlled via padconf
let trst( bool level ) -> void {  sim_input( 0x0a1c, level );  }
let tck(  bool level ) -> void {  sim_input( 0x0a1e, level );  }
let tms(  bool level ) -> void {  sim_input( 0x0a20, level );  }
let tdi(  bool level ) -> void {  sim_input( 0x0a22, level );  }

// JTAG output (TDO) monitored via gpio
let tdo() -> bool {
	return 0;
}

// TDO unavailable
let static tdo_init()
{
}

// RTCK unavailable
let rtck() -> bool {  return false;  }

let hw_init() -> void
{
	padconf_regs = (u16 *)map_phys( 0x4800'2000, 0x1000 );

	if( has_tdo )
		tdo_init();
}

[-- Attachment #3: hw-omap3.h --]
[-- Type: text/x-chdr, Size: 789 bytes --]

#pragma once
#include "defs.h"


let hw_init() -> void;


//-------------- JTAG pin i/o ------------------------------------------------//

// control JTAG inputs
let trst( bool out ) -> void;
let tck(  bool out ) -> void;
let tms(  bool out ) -> void;
let tdi(  bool out ) -> void;

// monitor JTAG output
let tdo() -> bool;
let rtck() -> bool;

let constexpr has_tdo = false;
let constexpr has_rtck = false;


//-------------- Debug hw config ---------------------------------------------//

constexpr u32 idcode_mask  = 0x0'ffff'fff;
constexpr u32 idcode_match = 0x0'b7ae'02f;

// initialization of icepick registers
constexpr u32 icepick_init_regs[] = {
	0x23'002100,  // assert cortex-a8 DBGEN
};

// address of cortex-a8 debug regs on debug APB
constexpr u32 a8_debug = 0x54011'000;

[-- Attachment #4: hw-usbblaster.cc --]
[-- Type: text/x-c++src, Size: 1607 bytes --]

#include "defs.h"
#include "hw-omap3.h"
#include "die.h"

#include <ftdi.h>

/* see usb-blaster-protocol.txt */
#define BLASTER_TCK	(1 << 0)
#define BLASTER_TMS	(1 << 1)
#define BLASTER_NCE	(1 << 2)
#define BLASTER_TDI	(1 << 4)
#define BLASTER_LED	(1 << 5)
#define BLASTER_READ	(1 << 6)

static struct ftdi_context ftdic;
static u8 blaster_byte;

//-------------- JTAG pin i/o ------------------------------------------------//

let static sim_input( u8 mask, bool level )
{
	int ret;

	if (level)
		blaster_byte |= mask;
	else
		blaster_byte &= ~mask;

	ret = ftdi_write_data(&ftdic, &blaster_byte, 1);
	if (ret != 1)
		die("ftdi_write_data %d\n", ret);
}

// JTAG inputs
let trst( bool level ) -> void {  sim_input( BLASTER_NCE, level );  }
let tck(  bool level ) -> void {  sim_input( BLASTER_TCK, level );  }
let tms(  bool level ) -> void {  sim_input( BLASTER_TMS, level );  }
let tdi(  bool level ) -> void {  sim_input( BLASTER_TDI, level );  }

// JTAG output (TDO)
let tdo() -> bool {
	static u8 byte;
	int ret;

	do {
		ret = ftdi_read_data(&ftdic, &byte, 1);
	}
	while (ret == 1);

	if (ret != 0 && ret != 1)
		die("ftdi_read_data %d\n", ret);

	return byte & 1;
}

// RTCK unavailable
let rtck() -> bool {  return false;  }

let hw_init() -> void
{
	if (ftdi_init(&ftdic) < 0)
		die("ftdi_init\n");

	if (ftdi_usb_open(&ftdic, 0x09fb, 0x6001) < 0)
		die("ftdi_usb_open\n");

	if (ftdi_usb_reset(&ftdic) < 0)
		die("ftdi_usb_reset\n");

	if (ftdi_set_latency_timer(&ftdic, 2) < 0)
		die("ftdi_set_latency_timer\n");

	ftdi_disable_bitbang(&ftdic);

	blaster_byte = BLASTER_LED | BLASTER_READ;
}

Re: Enabling DBGEN signal in GP OMAP3

[Matthijs van Duin]

On 26 February 2015 at 02:09, Grazvydas Ignotas <notasas@gmail.com> wrote:
> I've finally got rid of nTRST pulldown (haven't connected TDO though),
> created hw-omap3.{h,cc}, but couldn't get it to do anything, until it
> came to my mind that you may be running ARM on your BBB slower that
> 1GHz that I'm using on my DM3730. So lowered the clock to 500MHz and
> voila, it worked!

I'm actually running at 1 GHz also, but I must admit I only assumed no
explicit delays would be necessary when bit-banging, I didn't actually
check to see what kind of TCK speed it produced. It's actually
slightly surprising to me that the CPU would end up the bottleneck.

Enabling TDO will also assuredly slow things down incredibly: without
it I'm just doing writes, which are posted (aka buffered / performed
asynchronously), while inserting a read will stall the cpu until it
gets an answer from the peripheral.

Thinking of it... unless the control module and relevant GPIO module
are connected to the same L4 interconnect (which they aren't in my
test case) I should actually perform at least a dummy read (aka "OCP
barrier") from the control module before accessing GPIO since
otherwise it's not even guaranteed that all writes to the control
module have completed. Joy.

If you want guaranteed reliability, modify tck_pulse() to insert
aforementioned barrier + an actual delay at all three points where I
put comments about them.  usleep(50) or so should do the job.

> I guess I'll still connect TDO as it's not so much fun without it,
> going to try connecting to EMU0 too, hopefully it doesn't mess up the
> boot modes.

Note that you can use *any* gpio. I just used one of the EMU pins
because the am335x lets you reconfigure those to GPIO and it was
conveniently nearby. Anyhow, even if you do use EMU0 (or EMU1) for
this, TDO is only driven during data transfers and high-Z otherwise,
so you'd need very good aim with your power-on-reset pulse to manage
to get the EMU pin sampled low (assuming the line even has enough
capacitance to avoid being pulled up fast enough).

> My main goal is to have hardware watchpoints on the cased production
> unit without extra hardware, and it looks like I can finally have
> that, thanks!

You're welcome!

> It sure is! The only thing I do not understand is why are you using
> that process_vm_readv() call, mmap() already makes unprivileged user
> mode writable mappings.

Obviously, otherwise process_vm_readv() would give EFAULT also.

The issue here is not the MMU but the control module itself. I don't
know the situation on the omap3, but at least on recent SoCs the
control module checks the request privilege (OCP MReqSupervisor
signal) and ignores all unprivileged writes. In this case that request
flag comes from the AWPROT[0] signal of the AXI bus, which (for
uncacheable writes) is set based on the CPU processor mode with which
the store-instruction is executed.

Matthijs

Re: Enabling DBGEN signal in GP OMAP3

[Matthijs van Duin]

On 26 February 2015 at 02:09, Grazvydas Ignotas <notasas@gmail.com> wrote:
> And hey, it worked too with your code modified to use
> USB Blaster in it's bitbang mode over libftdi. This setup also works
> with openocd, but somewhat unreliably (only occasionally gets through
> init, often gets register values it doesn't like).

I've never had much luck with OpenOCD either... it doesn't handle
ICEPick very well, nor DAP for that matter: e.g. you can't connect to
DAP without also connecting to a processor, and it can't deal with
WAIT responses so you need to configure it to worst-case timings
(nearly impossible to estimate) or hope AP responses never get delayed
due to interconnect congestion or clock speed changes.

> Anyway I'm attaching my code too

Ah, if this works then apparently the omap3 control module doesn't
check privilege.

BTW, is this comment in hw-omap3.h true?

> 0x23'002100, // assert cortex-a8 DBGEN

My impression was that bit 13 of DAP's tap control register either
does nothing or at most enables the DAPCTL registers to be written,
but that setting bit 13 of the DAP_PC_FER register would still be
needed to assert DBGEN.

Also,

> // address of cortex-a8 debug regs on debug APB
> constexpr u32 a8_debug = 0x54011'000;

If bit 31 isn't set, then these writes should (afaik) be equivalent to
just performing them directly through the interconnect instead of
using JTAG.

I should maybe have mentioned that without TDO, my example doesn't
actually verify debug authentication status. It does perform a test
that debug APB writes are working by using the debug communications
channel, but I don't think this requires DBGEN to be asserted.

Re: Enabling DBGEN signal in GP OMAP3

[Grazvydas Ignotas]

On Thu, Feb 26, 2015 at 5:14 AM, Matthijs van Duin
<matthijsvanduin@gmail.com> wrote:
> Thinking of it... unless the control module and relevant GPIO module
> are connected to the same L4 interconnect (which they aren't in my
> test case) I should actually perform at least a dummy read (aka "OCP
> barrier") from the control module before accessing GPIO since
> otherwise it's not even guaranteed that all writes to the control
> module have completed. Joy.
>
> If you want guaranteed reliability, modify tck_pulse() to insert
> aforementioned barrier + an actual delay at all three points where I
> put comments about them.  usleep(50) or so should do the job.

Adding just the barrier works reliably for me, even at 1GHz.

>> I guess I'll still connect TDO as it's not so much fun without it,
>> going to try connecting to EMU0 too, hopefully it doesn't mess up the
>> boot modes.
>
> Note that you can use *any* gpio. I just used one of the EMU pins
> because the am335x lets you reconfigure those to GPIO and it was
> conveniently nearby.

Same here for me, this allowed to avoid adding a long wire which could
interfere with case parts, etc.
I've already performed the mod (just a solder bridge) and it works fine.

On Thu, Feb 26, 2015 at 6:01 AM, Matthijs van Duin
<matthijsvanduin@gmail.com> wrote:
> On 26 February 2015 at 02:09, Grazvydas Ignotas <notasas@gmail.com> wrote:
>
>> Anyway I'm attaching my code too
>
> Ah, if this works then apparently the omap3 control module doesn't
> check privilege.

Yeah, even OMAP5 doesn't do it for me.

> BTW, is this comment in hw-omap3.h true?
>
>> 0x23'002100, // assert cortex-a8 DBGEN
>
> My impression was that bit 13 of DAP's tap control register either
> does nothing or at most enables the DAPCTL registers to be written,
> but that setting bit 13 of the DAP_PC_FER register would still be
> needed to assert DBGEN.

Yes you're right, I've cleared bit 13 and everything works same way as
before, and in all cases additional ap_write() is needed to actually
set DBGEN.

>
> Also,
>
>> // address of cortex-a8 debug regs on debug APB
>> constexpr u32 a8_debug = 0x54011'000;
>
> If bit 31 isn't set, then these writes should (afaik) be equivalent to
> just performing them directly through the interconnect instead of
> using JTAG.

I don't know about that... To enable DBGEN, I just do:
ap_write( 0x5401d030, 0x00002000 );
and it works. Using 0xd401d030 seems to work too.


Thanks again,
Gražvydas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Enabling DBGEN signal in GP OMAP3

[Matthijs van Duin]

On 1 March 2015 at 01:03, Grazvydas Ignotas <notasas@gmail.com> wrote:
> On Thu, Feb 26, 2015 at 5:14 AM, Matthijs van Duin wrote:
>> If you want guaranteed reliability, modify tck_pulse() to insert
>> aforementioned barrier + an actual delay at all three points where I
>> put comments about them.  usleep(50) or so should do the job.
>
> Adding just the barrier works reliably for me, even at 1GHz.

Yeah I just realized that usleep is a bit larger than I intended... by
a factor 1000. Whoops :) In fact even 50 ns would be excessive but I
wanted to be on the safe side.  It doesn't surprise me that sending
(and waiting for) a ping all the way to the L4WK suffices in practice.

>> Ah, if this works then apparently the omap3 control module doesn't
>> check privilege.
>
> Yeah, even OMAP5 doesn't do it for me.

Hmm, based on a quick browse of TRMs, this restriction indeed seems specific to
centaurus, subarctic, and aegis. Curious.


>> If bit 31 isn't set, then these writes should (afaik) be equivalent to
>> just performing them directly through the interconnect instead of
>> using JTAG.
>
> I don't know about that... To enable DBGEN, I just do:
> ap_write( 0x5401d030, 0x00002000 );
> and it works. Using 0xd401d030 seems to work too.

That's... unexpected.

Normally on a CoreSight debug APB, bit 31 identifies requests as
coming from the debugger. It would normally set it, but can clear it
to simulate application (= non-debug) access.

An example of this difference is that application code typically needs
to unlock access to a CoreSight debug peripheral before it can write
to them, while debuggers are exempt. This is reflected in the
LOCKSTATUS register:
00001fb4: 00000003   // lock present and engaged
80001fb4: 00000000   // no lock present

TI SoCs don't really have a debug APB as such, instead the APB-AP
routing on e.g. centaurus and subarctic is:
if( ( addr & 0x7ff'ff'000 ) == 0x000'40'000 ) {
        target = dap_cs_rom;
        addr &= 0xfff;
} else {
        target = l4emu;
        debug = addr >> 31;  // OCP MReqDebug signal
        addr &= 0x3f'fff;
}
with MReqDebug mapped back to bit 31 for APB targets.

Maybe the omap3 ignores bit 31, or it might be a quirk of DAPCTL to
check the initiator id rather than MReqDebug.

(Note BTW that using the L3 address happens to work in this case
because the higher bits are ignored. It might however cause an
unsuspecting reader to not realize that the APB-AP has a very
different address space and targets outside the L4EMU are not
reachable through it.)

> Thanks again,

You're welcome!