dbrownell [Fri, 2 Oct 2009 09:19:03 +0000 (09:19 +0000)]
Minor ETB and ETM bugfixes and doc updates
- ETB
* report _actual_ hardware status, not just expected status
* add a missing diagnostic on a potential ETB setup error
* prefix any diagnostics with "ETB"
- ETM
* make "etm status" show ETM hardware status too, instead of
just traceport status (which previously was fake, sigh)
- Docs
* flesh out "etm tracemode" docs a bit
* clarify "etm status" ... previously it was traceport status
* explain "etm trigger_percent" as a *traceport* option
ETM+ETB tracing still isn't behaving, but now I can see that part of
the reason is that the ETB turns itself off almost immediately after
being enabled, and before collecting any data.
Update release process documentation.
- Improve and clarify the wording of the introduction.
- Add section on version taggging.
- Some other minor corrections.
Add numeric version tag support to release script.
The release process itself does not use this support yet, but it allows
packagers to automate the process of managing their own tags, if they
patch the source code before releasing binaries. The release processes
should be revised to incorporate this feature to support -rc packages.
Fix release script bugs after experience from 0.2.0:
- The NEWS step failed due to an empty commit comment.
- The final release step would have failed, because the steps to switch
from the secure to insecure repository (and back again) require both
switch and a URL relocation steps
- Don't issue needless JTAG resets ... only do them after
errors. Normal exit now leaves every TAP in BYPASS.
- Fix an unlikely memory leak on one fault path.
- Remove the oddball limitation that invalid capture LSBs
trigger errors only for TAPs that support IDCODE.
Re the JTAG reset: there are too many of them, and they can
(and do!) change system state. So the needless ones should
get removed. This one was especially pointless.
- Commands were supposed to have been "arm11 memwrite ..."
not "memwrite ..."
- Get rid of obfuscatory macros
- Re-alphabetize
- Add docs for "arm11 vcr"
Update FT2232 driver so that it reliably enters TAP_RESET.
When the OpenOCD server starts up it records its state as TAP_RESET,
even though it could be anything. Then when it starts to examine
the scan chain, it calls jtag_add_tlr() which sees it doesn't have
any work to do, and so it does nothing. This can make the next
operations fail because they start from the wrong TAP state...
Instead of caring about the current recorded state, always enter
TAP_RESET by forcing five clocks with TMS high.
(NOTE: it seems most other JTAG adapter drivers have this same bug.)
Streamline Capture-IR handling and integrity test.
Change the handling of the "-ircapture" and "-irmask" parameters
to be slightly more sensible, given that the JTAG spec describes
what is required, and that we already require that conformance in
one place. IR scan returns some bitstring with LSBs "01".
- First, provide and use default values that satisfy the IEEE spec.
Existing TAP configs will override the defaults, but those parms
are no longer required.
- Second, warn if any TAP gets set up to violate the JTAG spec.
It's likely a bug, but maybe not; else this should be an error.
Improve the related diagnostics to say which TAP is affected.
And associated minor fixes/cleanups to comments and diagnostics.
When attaching GDB to OpenOCD, the target state is no longer affected.
Added gdb_sync feature that allows GDB to sync up to target state.
Issue "monitor gdb_sync" and the next stepi, will return immediately
with updated register values to GDB.
Start handling the (second) SRST stage of reset better:
make sure that when there are two or more targets, their
various pre/post event reports are correctly ordered.
Previously, only the first target always saw its "pre"
method before SRST was asserted or deasserted.
When setting up an ETM, cache its ETM_CONFIG register. Then
only expose the registers which are actually present. They
could be missing for two basic reasons:
- This version might not support them at all; e.g. ETMv1.1
doesn't have some control/status registers. (My sample of
ARM9 boards shows all with ETMv1.3 support, FWIW.)
- The configuration on this chip may not populate as many
registers as possible; e.g. only two data value comparators
instead of eight.
Includes a bugfix in the "etm info" command: only one of the
two registers is missing on older silicon, so show the first
one before bailing.
Update ETM usage docs to explain that those registers need to be
written to configure what is traced, and that some ETM configs
are not yet handled. Also, give some examples of the kinds of
constrained trace which could be arranged.
Start cleaning up ETM register handling. On one ARM926 ETM+ETB
system, removes 20 non-existent registers ... but still includes
over 45 (!) ETM registers which don't even exist there ...
- Integrate the various tables to get one struct per register
- Get rid of needless per-register dynamic allocation
- Double check list of registers:
* Remove sixteen (!) non-registers for data comparators
* Remove four registers that imply newer ETM than we support
* Change some names to match current architecture specs
- Handle more register info
* some are write-only
* some are read-only
* record which versions have them, just in case
- Reorganize the registers to facilitate removing the extras
* group e.g. comparator/counter #N registers together
* add and use lookup-by-ID
- Add a header comment
- Line up the ETM context struct, pack it a bit
- Remove unused context_id (this doesn't support ETMv2 yet)
- Make most functions static
- Remove unused string table and other needless lines of code
- Correct "tracemode" helptext
Also provide and use an etm_reg_lookup() to find entries in the ETM
register cache. This will help cope with corrected contents of that
cache, which doesn't include entires for non-existent registers.
Nico Coesel <ncoesel@dealogic.nl> fix warnings. . I'm wondering why these
didn't turn up earlier. Is everyone still using gcc 3.x? Or is the x86
version of gcc 4.x much more relaxed?
Update the jtag-examine_chain() logic to verify that there's no
garbage after the expected data (from the TAPs' BYPASS or IDCODE
registers).
NOTE that there was previously some code that looked like it was
trying to do this ... which didn't work, because it was looping
over the list of expected TAPs, and never checked *after* that
list completed! That could hide some *nasty* reset issues...
Also replace a now-obsolete scanchain length test with one that
behaves correctly; and update reporting of unexpected IDCODEs.
Update the User's Guide to cover the scan chain verification step
done on exit from the config stage, how JTAG clocking issues can
trigger errors there, and how to avoid such problems.
Minor regression bugfix for the jtag_tap_handle_event() case
for disabling TAPs. We don't actually know how to make any
JRCs which do that yet; but when we do, this will matter.
Minor behavior fixes for the two JTAG reset events (C/internal,
and Tcl/external):
- Reorder so *both* paths (TCK/TMS or TRST) can enable TAPs with
ICEpick ... first C code flags TAPs that got disabled, then call
any Tcl code that might want to re-enable them.
- Always call the C/internal handlers when JTAG operations can be
issued; previously that wasn't done when TRST was used.
Plus some small cleanups (whitespace, strings, better messaging
during debug and on some errors) to reset-related code.
Erase logic:
- command invocation
+ treat "nand erase N" (no offset/length) as "erase whole chip N"
+ catch a few more bogus parameter cases, like length == 0 (sigh)
- nand_erase() should be static
- on error
+ say which block failed, and if it was a bad block
+ don't give up after the first error; try to erase the rest
- on success, say which nand device was erased (name isn't unique)
Device list ("nand list"):
- say how many blocks there are
- split summary into two lines
- give example in the docs
Doc tweaks:
- Use @option{...} for DaVinci's supported hardware ECC options
For the record, I've observed that _sometimes_ erasing bad blocks causes
failure reports, and that manufacturer bad block markers aren't always
erasable (even when erasing their blocks doesn't trigger an error report).
michal smulski <michal.smulski@ooma.com> fix regression in jtag_add_pathmove() which broke arm11 in r1825. Other uses of jtag_add_pathmove are svn + xsvf + xscale...
srst_gates_jtag option. at91sam9260 needs retesting, and possibly srst_gates_jtag added to reset_config. Could i.MX27 be a case where srst does not pull trst, but really srst gates jtag clock?
The "arm9tdmi.c" file is more of a generic ARM9 support file:
- update comments to say so.
- update docs to clarify that the "arm9tdmi" command prefix
is a misnomer.
- bugfix some messages that wrongly assume only ARM9TDMI
based processors use this code.
Doc update: mention how ARM's WFI instruction affects
JTAG clocking by gating the core clock, and workarounds.
Most details are with the "halt" command, which is one
of the first places this issue will be noticed.
David Brownell <david-b@pacbell.net>
Update the board config for the DaVinci DM355 EVM so the reset-init
event handler does the rest of the work it should do:
- minor PLL setup bugfixes
- initialize the DDR2 controller
- probe both NAND banks
- initialize UART0
- enable the icache
projects / openocd / log