* Enabling DBGEN signal in GP OMAP3 @ 2015-02-15 21:30 Grazvydas Ignotas 2015-02-16 17:58 ` Tony Lindgren 2015-02-16 18:43 ` Matthijs van Duin 0 siblings, 2 replies; 17+ messages in thread From: Grazvydas Ignotas @ 2015-02-15 21:30 UTC (permalink / raw) To: linux-omap Cc: Matthijs van Duin, Nishanth Menon, Santosh Shilimkar, Will Deacon 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Enabling DBGEN signal in GP OMAP3 2015-02-15 21:30 Enabling DBGEN signal in GP OMAP3 Grazvydas Ignotas @ 2015-02-16 17:58 ` Tony Lindgren 2015-02-16 20:09 ` Matthijs van Duin 2015-02-16 18:43 ` Matthijs van Duin 1 sibling, 1 reply; 17+ messages in thread From: Tony Lindgren @ 2015-02-16 17:58 UTC (permalink / raw) To: Grazvydas Ignotas Cc: linux-omap, Matthijs van Duin, Nishanth Menon, Santosh Shilimkar, Will Deacon * 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Enabling DBGEN signal in GP OMAP3 2015-02-16 17:58 ` Tony Lindgren @ 2015-02-16 20:09 ` Matthijs van Duin 2015-02-17 23:37 ` Grazvydas Ignotas 2015-02-18 14:54 ` Tony Lindgren 0 siblings, 2 replies; 17+ messages in thread From: Matthijs van Duin @ 2015-02-16 20:09 UTC (permalink / raw) To: Tony Lindgren Cc: Grazvydas Ignotas, linux-omap, Nishanth Menon, Santosh Shilimkar, Will Deacon 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Enabling DBGEN signal in GP OMAP3 2015-02-16 20:09 ` Matthijs van Duin @ 2015-02-17 23:37 ` Grazvydas Ignotas 2015-02-18 3:00 ` Matthijs van Duin 2015-02-18 14:54 ` Tony Lindgren 1 sibling, 1 reply; 17+ messages in thread From: Grazvydas Ignotas @ 2015-02-17 23:37 UTC (permalink / raw) To: Matthijs van Duin Cc: Tony Lindgren, linux-omap, Nishanth Menon, Santosh Shilimkar, Will Deacon [-- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Enabling DBGEN signal in GP OMAP3 2015-02-17 23:37 ` Grazvydas Ignotas @ 2015-02-18 3:00 ` Matthijs van Duin 2015-02-19 2:16 ` Grazvydas Ignotas 0 siblings, 1 reply; 17+ messages in thread From: Matthijs van Duin @ 2015-02-18 3:00 UTC (permalink / raw) To: Grazvydas Ignotas Cc: Tony Lindgren, linux-omap, Nishanth Menon, Santosh Shilimkar, Will Deacon 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). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Enabling DBGEN signal in GP OMAP3 2015-02-18 3:00 ` Matthijs van Duin @ 2015-02-19 2:16 ` Grazvydas Ignotas 2015-02-19 9:56 ` Matthijs van Duin 0 siblings, 1 reply; 17+ messages in thread From: Grazvydas Ignotas @ 2015-02-19 2:16 UTC (permalink / raw) To: Matthijs van Duin Cc: Tony Lindgren, linux-omap, Nishanth Menon, Santosh Shilimkar, Will Deacon 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Enabling DBGEN signal in GP OMAP3 2015-02-19 2:16 ` Grazvydas Ignotas @ 2015-02-19 9:56 ` Matthijs van Duin 2015-02-23 11:52 ` Matthijs van Duin 0 siblings, 1 reply; 17+ messages in thread From: Matthijs van Duin @ 2015-02-19 9:56 UTC (permalink / raw) To: Grazvydas Ignotas Cc: Tony Lindgren, linux-omap, Nishanth Menon, Santosh Shilimkar, Will Deacon 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Enabling DBGEN signal in GP OMAP3 2015-02-19 9:56 ` Matthijs van Duin @ 2015-02-23 11:52 ` Matthijs van Duin 2015-02-26 1:09 ` Grazvydas Ignotas 0 siblings, 1 reply; 17+ messages in thread From: Matthijs van Duin @ 2015-02-23 11:52 UTC (permalink / raw) To: Grazvydas Ignotas Cc: Tony Lindgren, linux-omap, Nishanth Menon, Santosh Shilimkar, Will Deacon 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Enabling DBGEN signal in GP OMAP3 2015-02-23 11:52 ` Matthijs van Duin @ 2015-02-26 1:09 ` Grazvydas Ignotas 2015-02-26 3:14 ` Matthijs van Duin 2015-02-26 4:01 ` Matthijs van Duin 0 siblings, 2 replies; 17+ messages in thread From: Grazvydas Ignotas @ 2015-02-26 1:09 UTC (permalink / raw) To: Matthijs van Duin Cc: Tony Lindgren, linux-omap, Nishanth Menon, Santosh Shilimkar, Will Deacon [-- 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; } ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Enabling DBGEN signal in GP OMAP3 2015-02-26 1:09 ` Grazvydas Ignotas @ 2015-02-26 3:14 ` Matthijs van Duin 2015-02-26 4:01 ` Matthijs van Duin 1 sibling, 0 replies; 17+ messages in thread From: Matthijs van Duin @ 2015-02-26 3:14 UTC (permalink / raw) To: Grazvydas Ignotas Cc: Tony Lindgren, linux-omap, Nishanth Menon, Santosh Shilimkar, Will Deacon 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Enabling DBGEN signal in GP OMAP3 2015-02-26 1:09 ` Grazvydas Ignotas 2015-02-26 3:14 ` Matthijs van Duin @ 2015-02-26 4:01 ` Matthijs van Duin 2015-03-01 0:03 ` Grazvydas Ignotas 1 sibling, 1 reply; 17+ messages in thread From: Matthijs van Duin @ 2015-02-26 4:01 UTC (permalink / raw) To: Grazvydas Ignotas Cc: Tony Lindgren, linux-omap, Nishanth Menon, Santosh Shilimkar, Will Deacon 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Enabling DBGEN signal in GP OMAP3 2015-02-26 4:01 ` Matthijs van Duin @ 2015-03-01 0:03 ` Grazvydas Ignotas 2015-03-01 1:52 ` Matthijs van Duin 0 siblings, 1 reply; 17+ messages in thread From: Grazvydas Ignotas @ 2015-03-01 0:03 UTC (permalink / raw) To: Matthijs van Duin Cc: Tony Lindgren, linux-omap, Nishanth Menon, Santosh Shilimkar, Will Deacon 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Enabling DBGEN signal in GP OMAP3 2015-03-01 0:03 ` Grazvydas Ignotas @ 2015-03-01 1:52 ` Matthijs van Duin 0 siblings, 0 replies; 17+ messages in thread From: Matthijs van Duin @ 2015-03-01 1:52 UTC (permalink / raw) To: Grazvydas Ignotas Cc: Tony Lindgren, linux-omap, Nishanth Menon, Santosh Shilimkar, Will Deacon 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! ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Enabling DBGEN signal in GP OMAP3 2015-02-16 20:09 ` Matthijs van Duin 2015-02-17 23:37 ` Grazvydas Ignotas @ 2015-02-18 14:54 ` Tony Lindgren 2015-02-18 18:28 ` Matthijs van Duin 1 sibling, 1 reply; 17+ messages in thread From: Tony Lindgren @ 2015-02-18 14:54 UTC (permalink / raw) To: Matthijs van Duin Cc: Grazvydas Ignotas, linux-omap, Nishanth Menon, Santosh Shilimkar, Will Deacon * 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Enabling DBGEN signal in GP OMAP3 2015-02-18 14:54 ` Tony Lindgren @ 2015-02-18 18:28 ` Matthijs van Duin 2015-02-18 22:56 ` Tony Lindgren 0 siblings, 1 reply; 17+ messages in thread From: Matthijs van Duin @ 2015-02-18 18:28 UTC (permalink / raw) To: Tony Lindgren Cc: Grazvydas Ignotas, linux-omap, Nishanth Menon, Santosh Shilimkar, Will Deacon 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Enabling DBGEN signal in GP OMAP3 2015-02-18 18:28 ` Matthijs van Duin @ 2015-02-18 22:56 ` Tony Lindgren 0 siblings, 0 replies; 17+ messages in thread From: Tony Lindgren @ 2015-02-18 22:56 UTC (permalink / raw) To: Matthijs van Duin Cc: Grazvydas Ignotas, linux-omap, Nishanth Menon, Santosh Shilimkar, Will Deacon * 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Enabling DBGEN signal in GP OMAP3 2015-02-15 21:30 Enabling DBGEN signal in GP OMAP3 Grazvydas Ignotas 2015-02-16 17:58 ` Tony Lindgren @ 2015-02-16 18:43 ` Matthijs van Duin 1 sibling, 0 replies; 17+ messages in thread From: Matthijs van Duin @ 2015-02-16 18:43 UTC (permalink / raw) To: Grazvydas Ignotas Cc: linux-omap, Nishanth Menon, Santosh Shilimkar, Will Deacon 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.) ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2015-03-01 1:53 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-02-15 21:30 Enabling DBGEN signal in GP OMAP3 Grazvydas Ignotas 2015-02-16 17:58 ` Tony Lindgren 2015-02-16 20:09 ` Matthijs van Duin 2015-02-17 23:37 ` Grazvydas Ignotas 2015-02-18 3:00 ` Matthijs van Duin 2015-02-19 2:16 ` Grazvydas Ignotas 2015-02-19 9:56 ` Matthijs van Duin 2015-02-23 11:52 ` Matthijs van Duin 2015-02-26 1:09 ` Grazvydas Ignotas 2015-02-26 3:14 ` Matthijs van Duin 2015-02-26 4:01 ` Matthijs van Duin 2015-03-01 0:03 ` Grazvydas Ignotas 2015-03-01 1:52 ` Matthijs van Duin 2015-02-18 14:54 ` Tony Lindgren 2015-02-18 18:28 ` Matthijs van Duin 2015-02-18 22:56 ` Tony Lindgren 2015-02-16 18:43 ` Matthijs van Duin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.