From: David B. <dbr...@us...> - 2009-12-27 21:24:35
|
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Main OpenOCD repository". The branch, master has been updated via 3ace333663628d00795fd0b5ab80c91e6025b4dc (commit) via 155a6a2c0bacdd4752e944ffd579d441361883db (commit) from 84dbf8ab5a2e85c9d9c9d276fba152a45a441433 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 3ace333663628d00795fd0b5ab80c91e6025b4dc Author: David Brownell <dbr...@us...> Date: Sun Dec 27 12:16:55 2009 -0800 create tcl/board/dm365evm.cfg This config is only lightly tested, and doesn't work well yet; but it's a start. * Notably missing is PLL configuration, since each DaVinci does that just a bit differently; and thus DDR2 setup. * The SRST workaround needed for the goof in the CPLD's VHDL depends on at least the not-yet-merged patch letting ARM9 (and ARM7) chips perform resets that don't use SRST. So this isn't yet suitable for debugging U-Boot. Signed-off-by: David Brownell <dbr...@us...> diff --git a/tcl/board/dm365evm.cfg b/tcl/board/dm365evm.cfg new file mode 100644 index 0000000..f8ec4e0 --- /dev/null +++ b/tcl/board/dm365evm.cfg @@ -0,0 +1,147 @@ +# DM365 EVM board -- Beta +# http://focus.ti.com/docs/toolsw/folders/print/tmdxevm365.html +# http://support.spectrumdigital.com/boards/evmdm365 + +source [find target/ti_dm365.cfg] + +# NOTE: in Rev C boards, the CPLD ignores SRST from the ARM-20 JTAG +# connector, so it doesn't affect generation of the reset signal. +# Accordingly, resets require something else. ICEpick could do it; +# but its docs aren't generally available. +# +# At this writing, newer boards aren't available ... so assume no SRST. +# Also ICEpick docs aren't available ... so we must use watchdog reset, +# and hope the CPU isn't wedged or in a WFI loop (either of which can +# block access to CPU and thus watchdog registers). + +reset_config trst_only +$_TARGETNAME configure -event reset-assert "davinci_wdog_reset" + +# SW5.1 routes CS0: NAND vs OneNAND. +# SW4.6:4 controls AEMIF width (8 for NAND, 16 for OneNand) +# for boot-from-flash, those must agree with SW4.3:1 settings. + +if { [info exists CS0MODE] } { + # NAND or OneNAND + set CS0 $CS0MODE +} else { + set CS0 "" + echo "WARNING: CS0 configuration not known" + proc cs0_setup {a_emif} {} + proc flashprobe {} {} +} + +set a_emif [dict get $dm365 a_emif] + +# As shipped: boot from NAND. +if { $CS0 == "NAND" } { + echo "CS0 NAND" + + # NAND socket has two chipselects. Default MT29F16G08FAA chip + # has 1GByte on each one. + # NOTE: "hwecc4" here presumes that you're not updating anything + # that needs infix layout (e.g. UBL, old U-Boot, etc) + nand device low davinci $_TARGETNAME 0x02000000 hwecc4 $a_emif + nand device high davinci $_TARGETNAME 0x02004000 hwecc4 $a_emif + + proc cs0_setup {a_emif} { + global dm365 + + # 8 bit EMIF + davinci_pinmux $dm365 2 0x00000016 + + # slow/pessimistic timings + set nand_timings 0x40400204 + # fast (25% faster page reads) + #set nand_timings 0x0400008c + + # CS0 == socketed NAND (default MT29F16G08FAA, 2 GBytes) + mww [expr $a_emif + 0x10] $nand_timings + + # NANDFCR -- CS0 has NAND + mww [expr $a_emif + 0x60] 0x01 + } + proc flashprobe {} { + nand probe 0 + nand probe 1 + } + +} elseif { $CS0 == "OneNAND" } { + echo "CS0 OneNAND" + + # No support for this OneNAND in OpenOCD (yet) or Linux ... + # REVISIT OneNAND timings not verified to work! + echo "WARNING -- OneNAND not yet tested!" + + proc cs0_setup {a_emif} { + global dm365 + + # 16 bit EMIF + davinci_pinmux $dm365 2 0x00000055 + + # CS0 == OneNAND (KFG1G16U2B-DIB6, 128 KBytes) + mww [expr $a_emif + 0x10] 0x00000001 + + # ONENANDCTRL -- CS0 has OneNAND, enable sync reads + mww [expr $a_emif + 0x5c] 0x0441 + } + proc flashprobe {} { } +} + +# NOTE: disable or replace this call to dm365evm_init if you're +# debugging new UBL/NANDboot code from SRAM. +$_TARGETNAME configure -event reset-init { dm365evm_init } + +# +# This post-reset init is called when the MMU isn't active, all IRQs +# are disabled, etc. It should do most of what a UBL does, except for +# loading code (like U-Boot) into DRAM and running it. +# +proc dm365evm_init {} { + global dm365 + + echo "Initialize DM365 EVM board" + + # CLKIN = 24 MHz ... can't talk quickly to ARM yet + jtag_khz 1500 + + # FIXME -- PLL init + + ######################## + # PINMUX setup + + davinci_pinmux $dm365 0 0x00fd0000 + davinci_pinmux $dm365 1 0x00145555 + # mux2 controls AEMIF ... 8 bit for NAND, 16 for OneNand + davinci_pinmux $dm365 3 0x375affff + davinci_pinmux $dm365 4 0x55556555 + + ######################## + # PSC setup (minimal) + + # DDR EMIF/13, AEMIF/14, UART0/19 + psc_enable 13 + psc_enable 14 + psc_enable 19 + psc_go + + # FIXME setup DDR2 (needs PLL) + + ######################## + # ASYNC EMIF + + set a_emif [dict get $dm365 a_emif] + + # AWCCR + mww [expr $a_emif + 0x04] 0xff + # CS0 == NAND or OneNAND + cs0_setup $a_emif + # CS1 == CPLD + mww [expr $a_emif + 0x14] 0x00a00505 + + # FIXME setup UART0 + + flashprobe +} + + commit 155a6a2c0bacdd4752e944ffd579d441361883db Author: David Brownell <dbr...@us...> Date: Sun Dec 27 11:34:31 2009 -0800 NOR: make flash_write_unlock() pad to sector end Resolve a regression when using newish automagic "write_image" modes, by always padding to the end of affected sectors. Also document some issues associated with those automagic options, in the User's Guide and also some related code comments. We might need similar padding at the *beginning* of some sectors, but this is a minimalist fix for the problems which have currently been reported (plus doc updates). Signed-off-by: David Brownell <dbr...@us...> diff --git a/doc/openocd.texi b/doc/openocd.texi index 1c20716..154ecbc 100644 --- a/doc/openocd.texi +++ b/doc/openocd.texi @@ -3857,8 +3857,29 @@ explicitly as @option{bin} (binary), @option{ihex} (Intel hex), The relevant flash sectors will be erased prior to programming if the @option{erase} parameter is given. If @option{unlock} is provided, then the flash banks are unlocked before erase and -program. The flash bank to use is inferred from the @var{address} of -each image segment. +program. The flash bank to use is inferred from the address of +each image section. + +@quotation Warning +Be careful using the @option{erase} flag when the flash is holding +data you want to preserve. +Portions of the flash outside those described in the image's +sections might be erased with no notice. +@itemize +@item +When a section of the image being written does not fill out all the +sectors it uses, the unwritten parts of those sectors are necessarily +also erased, because sectors can't be partially erased. +@item +Data stored in sector "holes" between image sections are also affected. +For example, "@command{flash write_image erase ...}" of an image with +one byte at the beginning of a flash bank and one byte at the end +erases the entire bank -- not just the two sectors being written. +@end itemize +Also, when flash protection is important, you must re-apply it after +it has been removed by the @option{unlock} flag. +@end quotation + @end deffn @section Other Flash commands diff --git a/src/flash/nor/core.c b/src/flash/nor/core.c index fe5372b..5eb51cd 100644 --- a/src/flash/nor/core.c +++ b/src/flash/nor/core.c @@ -439,9 +439,26 @@ int flash_write_unlock(struct target *target, struct image *image, { if (image->sections[section_last + 1].base_address < (run_address + run_size)) { - LOG_DEBUG("section %d out of order(very slightly surprising, but supported)", section_last + 1); + LOG_DEBUG("section %d out of order " + "(surprising, but supported)", + section_last + 1); + /* REVISIT this can break with autoerase ... + * clobbering data after it's written. + */ break; } + + /* REVISIT This needlessly touches sectors BETWEEN the + * sections it's writing. Without auto erase, it just + * writes ones; unlikely to destroy data. + * + * With auto erase enabled, data in those sectors will + * be needlessly destroyed; and some of the limited + * number of flash erase cycles will be wasted... + * + * In both cases, the extra writes slow things down. + */ + /* if we have multiple sections within our image, flash programming could fail due to alignment issues * attempt to rebuild a consecutive buffer for the flash loader */ pad_bytes = (image->sections[section_last + 1].base_address) - (run_address + run_size); @@ -450,7 +467,6 @@ int flash_write_unlock(struct target *target, struct image *image, padding[section_last] = pad_bytes; run_size += image->sections[++section_last].size; run_size += pad_bytes; - padding[section_last] = 0; LOG_INFO("Padding image section %d with %d bytes", section_last-1, pad_bytes); } @@ -458,11 +474,35 @@ int flash_write_unlock(struct target *target, struct image *image, /* fit the run into bank constraints */ if (run_address + run_size - 1 > c->base + c->size - 1) { + /* REVISIT isn't this superfluous, given the while() + * loop conditions above?? + */ LOG_WARNING("writing %d bytes only - as image section is %d bytes and bank is only %d bytes", \ (int)(c->base + c->size - run_address), (int)(run_size), (int)(c->size)); run_size = c->base + c->size - run_address; } + /* If we're applying any sector automagic, then pad this + * (maybe-combined) segment to the end of its last sector. + */ + if (unlock || erase) { + int sector; + uint32_t offset_start = run_address - c->base; + uint32_t offset_end = offset_start + run_size; + uint32_t end = offset_end, delta; + + for (sector = 0; sector < c->num_sectors; sector++) { + end = c->sectors[sector].offset + + c->sectors[sector].size; + if (offset_end <= end) + break; + } + + delta = end - offset_end; + padding[section_last] += delta; + run_size += delta; + } + /* allocate buffer */ buffer = malloc(run_size); buffer_size = 0; ----------------------------------------------------------------------- Summary of changes: doc/openocd.texi | 25 ++++++++- src/flash/nor/core.c | 44 ++++++++++++++- tcl/board/dm365evm.cfg | 147 ++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 212 insertions(+), 4 deletions(-) create mode 100644 tcl/board/dm365evm.cfg hooks/post-receive -- Main OpenOCD repository |