at91samd: add erase/secure commands, minor fix

Reference code for the SAMD2x disables caching in the NVM controller when
issuing NVM commands.  Let's do this as well to be consistent and safer.

Add a "chip-erase" for the Atmel SAMD targets that issues a complete Chip Erase
via the Device Service Unit (DSU).  This can be used to "unlock" or otherwise
unbrick a chip that can't be halted or inspected, allowing the user to reflash
with new firmware.

Add a "set-security" command which issues an SSB.  Once that's done and the
device is power-cycled, the flash cannot be written to until a "chip-erase" is
issued.  The chip-erase cannot be issued by openocd at this time because
the device will not respond to a request for the DAP IDCODE.

Change-Id: I80122f0bbf7e3aedffe052c1e77d69dc2dba25ed
Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>
Reviewed-on: http://openocd.zylin.com/2239
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
at91samd: fix protect, add EEPROM and boot commands

There were two problems with the _protect() feature:
1. The address written was off by a factor of two because the address
register takes 16-bit rather than 8-bit addresses.  As a result the
wrong sectors were (un)protected with the protect command.  This has
been fixed.
2. The protection settings issued via the lock or unlock region commands
don't persist after reset.  Making them persist requires modifying the
LOCK bits in the User Row using the infrastructure described below.

The Atmel SAMD2x MCUs provide a User Row (the size of which is one
page).  This contains a few settings that users may wish to modify from
the debugger, especially during production.  This change adds commands
to inspect and set:
- EEPROM size, the size in bytes of the emulated EEPROM region of the
  Flash.
- Bootloader size, the size in bytes of the protected "boot" section of
  the Flash.

This is done by a careful read-modify-write of the special User Row
page, avoiding erasing when possible and disallowing the changing of
documented reserved bits.  The Atmel SAMD20 datasheet was used for bit
positions and descriptions, size tables, etc. and testing was done on a
SAMD20 Xplained Pro board.

It's technically possible to store arbitrary user data (ex: serial
numbers, MAC addresses, etc) in the remaining portion of the User Row
page (that is, beyond the first 64 bits of it).  The infrastructure used
by the eeprom and bootloader commands can be used to access this as
well, and this seems safer than exposing the User Row as a normal Flash
sector that openocd understands due to the delicate nature of some of
the data stored there.

Change-Id: I29ca1bdbdc7884bc0ba0ad18af1b6bab78c7ad38
Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>
Reviewed-on: http://openocd.zylin.com/2326
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>