diff options
| author | David Brownell <dbrownell@users.sourceforge.net> | 2009-11-08 08:52:40 -0800 |
|---|---|---|
| committer | David Brownell <dbrownell@users.sourceforge.net> | 2009-11-08 08:52:40 -0800 |
| commit | 3e6f9e8d1e65c4da505ff78481d54a115520d3d1 (patch) | |
| tree | 71dba7d3285700e802edab7147ea0896d6e149ae /tcl/board/at91sam9g20-ek.cfg | |
| parent | 2b1bd97508ebaf33c76d4f36ec4bb85592801055 (diff) | |
| download | openocd_libswd-3e6f9e8d1e65c4da505ff78481d54a115520d3d1.tar.gz openocd_libswd-3e6f9e8d1e65c4da505ff78481d54a115520d3d1.tar.bz2 openocd_libswd-3e6f9e8d1e65c4da505ff78481d54a115520d3d1.tar.xz openocd_libswd-3e6f9e8d1e65c4da505ff78481d54a115520d3d1.zip | |
target.cfg: remove "-work-area-virt 0"
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>
Diffstat (limited to 'tcl/board/at91sam9g20-ek.cfg')
| -rw-r--r-- | tcl/board/at91sam9g20-ek.cfg | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/tcl/board/at91sam9g20-ek.cfg b/tcl/board/at91sam9g20-ek.cfg index 00ab7faf..6e8a1934 100644 --- a/tcl/board/at91sam9g20-ek.cfg +++ b/tcl/board/at91sam9g20-ek.cfg @@ -41,8 +41,8 @@ target create $_TARGETNAME arm926ejs -endian $_ENDIAN -chain-position $_TARGETNA # AT91SAM9G20 has two SRAM areas, one starting at 0x00200000 and the other starting at 0x00300000. # Both areas are 16 kB long. -$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x00200000 -work-area-size 0x4000 -work-area-backup 1 -$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x00300000 -work-area-size 0x4000 -work-area-backup 1 +#$_TARGETNAME configure -work-area-phys 0x00200000 -work-area-size 0x4000 -work-area-backup 1 +$_TARGETNAME configure -work-area-phys 0x00300000 -work-area-size 0x4000 -work-area-backup 1 # If you don't want to execute built-in boot rom code (and there are good reasons at times not to do that) in the # AT91SAM9 family, the microcontroller is a lump on a log without initialization. Because this family has |