olimex arm-usb-ocd + "avrdude -c arm-usb-ocd"

avrdude.conf

# this will interface with the chips on these programmers:
#
# http://real.kiev.ua/old/avreal/en/adapters
# http://www.amontec.com/jtagkey.shtml, jtagkey-tiny.shtml
# http://www.olimex.com/dev/arm-usb-ocd.html, arm-usb-tiny.html
# http://www.ethernut.de/en/hardware/turtelizer/index.html
# http://elk.informatik.fh-augsburg.de/hhweb/doc/openocd/usbjtag/usbjtag.html
# http://dangerousprototypes.com/docs/FT2232_breakout_board
# http://www.ftdichip.com/Products/Modules/DLPModules.htm,DLP-2232*,DLP-USB1232H
# http://flashrom.org/FT2232SPI_Programmer
# 
# The drivers will look for a specific device and use the first one found.
# If you have mulitple devices, then look for unique information (like SN)
# And fill that in here.
#
# Note that the pin numbers for the main ISP signals (reset, sck,
# mosi, miso) are fixed and cannot be changed, since they must match
# the way the Multi-Protocol Synchronous Serial Engine (MPSSE) of
# these FTDI ICs has been designed.

programmer
  id         = "avrftdi";
  desc       = "FT2232D based generic programmer";
  type       = "avrftdi";
  connection_type = usb;
  usbvid     = 0x0403;
  usbpid     = 0x6010;
  usbvendor  = "";
  usbproduct = "";
  usbdev     = "A";
  usbsn      = "";
#ISP-signals - lower ADBUS-Nibble (default)
  reset  = 3;
  sck    = 0;
  mosi   = 1;
  miso   = 2;
#LED SIGNALs - higher ADBUS-Nibble
#  errled = 4;
#  rdyled = 5;
#  pgmled = 6;
#  vfyled = 7;
#Buffer Signal - ACBUS - Nibble
#  buff   = 8;
;
programmer parent "avrftdi"
  id         = "arm-usb-ocd";
  desc       = "Olimex ARM-USB-OCD";
  usbvid     = 0x15ba;
  usbpid     = 0x0003;
  reset      = 4;
;

For some reason the bootloader ends up at 0x1e000 instead of 0x3e000, which indicates that something is wrong with the "load extended address" thing: https://forum.arduino.cc/index.php?topic=267440.msg4100956#msg4100956
avrftdi.c somehow deals with it in paged reads/writes, but differently for reading and writing, so it just might be broken. Also, maybe we don't even end up with paged writes, such that single-byte writes are used. As far as I can see, there's no avrftdi_lext() calls involved there.
So this might be a thing to investigate this evening ...