On 1 March 2015 at 01:03, Grazvydas Ignotas <notasas@xxxxxxxxx> 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!
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
