On Wed, Feb 18, 2015 at 5:00 AM, Matthijs van Duin <matthijsvanduin@xxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
