The semantics of "-work-area-virt 0" (or phys) changed with
the patch to require specifying physical or virtrual work
area addresses. Specifying zero was previously a NOP. Now
it means that address zero is valid.
This patch addresses three related issues:
- MMU-less processors should never specify work-area-virt;
remove those specifications. Such processors include
ARM7TDMI, Cortex-M3, and ARM966.
- MMU-equipped processors *can* specify work-area-virt...
but zero won't be appropriate, except in mischievous
contexts (which hide null pointer exceptions).
Remove those specs from those processors too. If any of
those mappings is valid, someone will need to submit a
patch adding it ... along with a comment saying what OS
provides the mapping, and in which context. Example,
say "works with Linux 2.6.30+, in kernel mode". (Note
that ARM Linux doesn't map kernel memory to zero ...)
- Clarify docs on that "-virt" and other work area stuff.
Seems to me work-area-virt is quite problematic; not every
operating system provides such static mappings; if they do,
they're not in every MMU context...
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Config for Intel's "Lubbock" PXA255 development board. Even more
so than the PXA255 itself, this is obsolete. AFAIK this was the
first generally available development platform for PXA255. Intel
stopped providing these after other devel boards became available.
One interesting thing about this board from the OpenOCD perspective
is probably its flash configuration. Each bank is 32 bits wide,
built from two 16-bit StrataFlash chips wired in parallel. This
doubles throughput ... it reads/writes 32 bits in the time a single
chip takes to write just 16 bits.
This conf mostly works, given XScale bugfixes, but has some issues
(notably: no access to the on-board SDRAM) flagged by FIXMEs.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
This is the very basic board config for the balloon3 board cpu JTAG
channel.
The rest of the config comprises another 14 .cfg files which I suspect
openocd doesn't really want all of. I'm still not sure how to deal
with this. I'll post another mail/patch to discuss.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Ofrwarded from Ron, who's not subscribed.
----- Forwarded message from Ron <ron@debian.org> -----
From: Ron <ron@debian.org>
Date: Wed, 14 Oct 2009 04:50:17 +1030
To: wookey@debian.org
Subject: [PATCH] OpenRD board configuration
X-Spam-Status: No, score=-3.6 required=4.5 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.2.5
This piggybacks on the 'sheevaplug' layout which uses the same Kirkwood SoC.
Signed-off-by: Ron Lee <ron@debian.org>
This is clearly noted in the hardware spec (section 5.2.3); it
works around a chip erratum: "If the MPU_RESET signal is used,
it may cause the EMIFS bus to lock."
I seem to have a board with such an initial build. The chip
is labeled XOMAP. Presumably, parts without that "X" prefix
(eXperimental) resolve this.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.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
git-svn-id: svn://svn.berlios.de/openocd/trunk@2699 b42882b7-edfa-0310-969c-e2dbd0fdcd60
defining ntrst_delay is pointless; don't.
At least the LM3S3748 eval board doesn't need nsrst_delay
either; remove that too.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2645 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Add flash programming support for NXP LPC1700 cortex_m3 based family
git-svn-id: svn://svn.berlios.de/openocd/trunk@2579 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Prepare the DaVinci PLL code to support the version 0x0E module
used in newer chips (e.g. dm365): rename the original code so
it's specific to version 0x02 PLL modules, and update the dm355evm
code to use that new name.
Fix two minor bugs in that version 2 code: sysclk3 setup used
the sysclk2 divider address (affecting video processing on dm355,
no worry for now) and sysclk2 setup had a syntax error.
Also minor fixups to dm355evm, mostly to permit use of RTCK.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2447 b42882b7-edfa-0310-969c-e2dbd0fdcd60
This patch adds support for the Luminary Micro LM3S9B90 target and
LM3S9B92 Evaluation Kit. These kits include a new ft2232 adapter, the
Luminary In-Circuit Debug Interface (ICDI) Board, so this is added as a
new ft2232 layout called "luminary_icdi".
git-svn-id: svn://svn.berlios.de/openocd/trunk@2429 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Improve the PXA255 target config: move all that board-specific
setup to the pxa255_sst board.cfg, to which it evidently belongs
(it's the only PXA255 board now included).
Provide the PXA255 JTAG id from Intel docs, and add a comment
about how this chip is now EOL'd (last orders taken).
Note that I still can't get my old PXA255 board to work. There's
something broken in the reset sequence, which is preventing the
TAP from coming up at all. Old mailing list posts suggest this
is a longstanding bug...
git-svn-id: svn://svn.berlios.de/openocd/trunk@2416 b42882b7-edfa-0310-969c-e2dbd0fdcd60
source the STM32 target config instead of using a private clone
git-svn-id: svn://svn.berlios.de/openocd/trunk@2352 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Update the Beagle setup:
- OMAP3530 updates:
* split ICEpick TAP enable support to its own file, for
reuse and eventually for storing other utility code
like emulation reset
* clean up, including labeling the tap as for DAP not
for the Cortex-A8 and making endianness non-variable
* add a few FIXMEs
- BeagleBoard cleanup: there's no SRST, "endstate" is gone, etc
I'm not sure I'd say it's further than "barely limping" just yet.
Key issues remain lack of Cortex-A8 support, and more complete
support for resetting.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2267 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Fix for a goofy "board" config ... reuse target/pxa270.cfg
instead of using a private copy.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2266 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Add another board ... OMAP2420 "H4" board. This won't be very widely
used with OpenOCD, but with mainline support in both U-Boot and Linux
it at least makes for a more complete set (and another testcase).
This is incomplete support in several respects. The ARM11 support is
not very deep yet; most registers aren't available, and the ETM can't
be hooked up. Plus, there's no script for OMAP-specific stuff like
setting up the SDRAM controller. Eventually the same NAND controller
driver should work with OMAP2 and OMAP3.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2242 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Tweak the csb337 code so that it doesn't enable alignment traps when
it completes the "reset init" sequence. It turns out that the current
CFI code reliably triggers such traps.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2179 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Add configuration for an old AT91rm9200 board, the Cogent CSB 337.
Worth noting from the OpenOCD perspective:
- It got a real hardware trace port connector; wired up here as
much as we can, lacking inexpensive trace-aware dongles.
- This is the first in-tree use of the "arm920t cp15" command.
It adjusts the CPU clocking and enables i-cache, which gives
more than 4x speedup after booting Linux; it's visible even
just running U-Boot.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2134 b42882b7-edfa-0310-969c-e2dbd0fdcd60
This is the missing half of the r1974 patch:
OSK5912 board support, which was split out from
the omap5912 target config.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1985 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- Move src/tcl to tcl/.
- Update top Makefile.am to use new path name.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1919 b42882b7-edfa-0310-969c-e2dbd0fdcd60
David Brownell
Wookey
Øyvind Harboe
Dean Glazeski
Rabeeh Khoury
oharboe
dbrownell
ntfreak
zwelch
duane