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
Dean Glazeski
Wookey
Øyvind Harboe
Rabeeh Khoury
David Brownell
oharboe
dbrownell
ntfreak
zwelch
duane