On 26 February 2015 at 02:09, Grazvydas Ignotas <notasas@xxxxxxxxx> 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. -- 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