openocd+libswd.git - Unnamed repository; edit this file 'description' to name the repository.

	Commit message (Collapse)	Author	Age	Files	Lines
*	David Brownell <david-b@pacbell.net>	oharboe	2009-09-09	1	-4/+7
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	Optionally shave time off the armv4_5 run_algorithm() code: let them terminate using software breakpoints, avoiding roundtrips to manage hardware ones. Enable this by using BKPT to terminate execution instead of "branch to here" loops. Then pass zero as the exit address, except when running on an ARMv4 core. ARM7TDMI, ARM9TDMI, and derived cores now set a flag saying they're ARMv4. Use that mechanism in arm_nandwrite(), for about 3% speedup on a DaVinci ARM926 core; not huge, but it helps. Some other algorithms could use this too (mostly flavors of flash operation). git-svn-id: svn://svn.berlios.de/openocd/trunk@2680 b42882b7-edfa-0310-969c-e2dbd0fdcd60
*	David Brownell	oharboe	2009-09-03	1	-0/+131
	Abstract the orion_nand_fast_block_write() routine into a separate routine -- arm_nandwrite() -- so that other ARM cores can reuse it. Have davinci_nand do so. This faster than byte-at-a-time ops by a factor of three (!), even given the slowish interactions to support hardware ECC (1-bit flavor in that test) each 512 bytes; those could be read more efficiently by on-chip code. NOTE that until there's a generic "ARM algorithm" structure, this can't work on newer ARMv6 (like ARM1136) or ARMv7A (like Cortex-A8) cores, though the downloaded code itself would work just fine there. git-svn-id: svn://svn.berlios.de/openocd/trunk@2663 b42882b7-edfa-0310-969c-e2dbd0fdcd60