Update README.md Make a new top-level "wiki" directory.

(because keeping the wiki pages in the source tree should allow other people to edit them and make pull requests, more easily that modifying the "protected" wiki pages (without making them fully publicly editable.)

README.md

@@ -4,23 +4,38 @@
 
 Optiboot is an easy to install upgrade to the Arduino bootloader within Arduino boards. It provides the following features:
 
-  * Allows larger sketches. Optiboot is a quarter of the size of the default bootloader, freeing 1.5k of extra space.
+  * Allows larger sketches. Optiboot is only 512 bytes, freeing 1.5k of extra code space compared to older bootloaders.
   * Makes your sketches upload faster. Optiboot operates at higher baud rates and has streamlined programming.
-  * Adaboot performance improvements. Optiboot runs your sketches sooner, with no watchdog issues.
-  * Compatible with 168 and 328 Arduinos including Lilypad, Pro, Nano
-  * Believed to work with ATmega1280 ("Mega"), ATmega644 ("Sanguino"), and ATmega1284 ("Mighty")
-  * Supports several additional AVR chips (ATmega88, ATmega32)
+  * Adaboot performance improvements. Optiboot implements "fastboot" that starts sketches immediate after power-on.
+  * Compatible with ATmega8, ATmega168, and ATmega328p Arduinos and derivatives including Lilypad, Pro, Nano, and many derivatives.
+  * Works with *MANY* additional Atmel AVR chips - almost anything that supoorts bootloads or "flash self-programming."  This includes chips from ATtiny 8pin chips through the 100pin ATmega2560 used on Arduino Mega.
+  * Supports alternate serial ports, cpu frequencies and baud rates.
 
-Optiboot is now installed by default on the Arduino Uno. It can be installed on all older mega8, 168 or 328 based Arduinos.
+Optiboot (an older version) is installed by default on the Arduino Uno and (as of 2018) official Arduino Nano boars.  It can be installed on all older mega8, 168 or 328 based Arduinos.
 
 ## Additional Documentation
 More detailed documentation is being added (slowly) to the [repository wiki](https://github.com/Optiboot/optiboot/wiki).
 
 ## Notes on IDE Version compatability
-Optiboot is "compatible", in a loose sense, with all versions of the Arduino IDE.  It was originally written at about the same time as v1.0, and has some "quirks" that date back to that timeframe.  Most significantly, install procedures and locations change between releases, and the ability to compile Optiboot using only the tools installed with the IDE broke in the v1.5 timeframe.
+Optiboot is "compatible", in a loose sense, with all versions of the Arduino IDE.  It was originally written at about the same time as v1.0, and has some "quirks" that date back to that timeframe.  Most significantly, the directory structure of the git repository is "weird."
 
 ## To install into the Arduino software ##
-You do NOT need to "install" Optiboot if you are trying to update an installed platform that already uses some form of Optiboot.  In that case, you should probably just find and replace the existing .hex files from the platform support directories.  Using the Optiboot "install" procedure does not install any cores or variants, so it is only useful for CPUs that are already supported by the standard Arduino core (or, if all you want to do is install bootloaders.)
+You do NOT need to "install" Optiboot if you are trying to update an installed platform that already uses some form of Optiboot.  In fact, you should almost certainly NOT install Optiboot using the board manager.
+The Optiboot github repository these days is mostly useful as a sorce-code repository, for anyone who needs to make a highly customized version for some reason.  Or an improvement to Optiboot itself.
+
+Most end users should find a supported "Arduino Core" that includes Optiboot for their desired target, and install that.  Many such cores are provided by the hardware vendor, and they'll include Board defintions, Variant files, and Arduino core code neeed to support the target as well as one or more Optiboot .hex files that should work.
+
+There are also some major repositories of "generic" versions of cores for various targets, including:
+
+  * [MegaCore by MCUdude](https://github.com/MCUdude/MegaCore) Supports large AVRs like ATmega128, ATmega640, ATmega1280, ATmega1281, ATmega2560 and ATmega2561.
+  * [MightyCore by MCUdude](https://github.com/MCUdude/MightyCore) Supports most 40pin AVRs including ATmega1284, ATmega644, ATmega324, ATmega32, and ATmega8535.
+  * [MiniCore by MCUdude](https://github.com/MCUdude/MiniCore) Supports most 28pin ATmega AVRs, including the cpus used by Uno/etc as well as the new cpus like the ATmega328PB.
+  * [MajorCore by MCUdude](https://github.com/MCUdude/MajorCore) Supports a couple of relatively obsolete large AVRs, like ATmega8515 and ATmega162.
+  * [ATTinyCore by Spence Konde](https://github.com/SpenceKonde/ATTinyCore) Supports many ATtiny AVRs, including ATtiny85, ATtiny1634, ATtiny84, and ATtiny841.
+
+If you need a new Optiboot feature not included in a pre-packaged core, the recommended procedure is to download or fork the source code, manually compile the version you need, and copy the .hex file to the existing board directory (after renaming the old .hex file, in case you need it back.)
+
+Nevertheless, there is an automatically installable Board Manager package that includes the .hex files for Optiboot on several popular Arduino boards (a very small subset of the possible targets.). Using the Optiboot "install" procedure does not install any cores or variants, so it is only useful for CPUs that are already supported by the standard Arduino core.
 
 The following instructions are based on using the Arduino "Board Manager", present in IDE versions 1.6.5 and later.
 
@@ -52,3 +67,4 @@ For additional installation information, see the [Optiboot AddingOptibootChipsTo
 
 > _Optiboot is the work of Peter Knight (aka Cathedrow). Despite some misattributions, it is not sponsored or supported by any organisation or company including Tinker London, Tinker.it! and Arduino._  
 > Maintenance of optiboot was taken over by Bill Westfield (aka WestfW) in 2011.
+> Major contributions have also been made by Hans "MCUdude", Spence "DrAzzy" Konde, and majekw.

Wiki/AddingOptibootChipsToIde.md

@@ -0,0 +1,20 @@
+# Not Done yet #
+
+This involves adding or editing a "boards.txt" file somewhere in the Arduino application or user sketch directory hierarchy.
+
+Both the preferred location and the format of the file change from version to version of the IDE.
+
+
+# IDE Version 1.6.4 (and later)
+## Boards Manager
+Verions 1.5.x (beta) of the IDE added support for a much broader range of non-AVR and 3rd party hardware.  This changed the directory structure in the user's sketchbook folder in ways that were incompatible with 1.0.x (in particular, adding a "platform" sub directory, so that boards.txt was in <sketchbook>/hardware/<extname>/<platformname>/)
+
+In 1.6.4 (a production release), the IDE added a "boards manager" that permits a 3rd party extension to be automatically downloaded and installed simply by adding a URL in the preferences panel and (in yet another location and clicking an "Install" button in the Boards Manager panel.  (The actual files end up in yet a different place in the file system, but this should be transparent to the users.)  This is the preferred way to install the Optiboot boards.txt if you are running 1.6.4 or later, but it does not (currently) install source code.
+
+# IDE version 1.0.x
+In version 1.0 of the Arduino IDE, it became possible to put hardware extensions in the sketchbook folder, by putting new subdirectories in <sketchbook>/hardware/<extname>.  You could put a suitably formatted boards.txt there describing the new optiboot cpus, pointing toward .hex files located in that tree, or in other locations.
+
+
+# IDE Version 00xx
+Optiboot was written prior to version 1.0 of the IDE.  In those days, the only way to add additional boards was to modify the boards.txt file that included within the directory structure of the IDE itself. (<installDir>/hardware/arduino/boards.txt, with the .hex files in <installDir>/hardware/arduino/bootloaders/optiboot)  The directory structure of the Optiboot repositor reflects this old structure.
+

Wiki/BootloaderIntro.txt

@@ -0,0 +1,21 @@
+What is a "Bootloader" ?
+
+What is "stk500" ?
+
+What is "avrdude" ?
+
+What symptoms indicate a bootloading problem?
+
+What are common causes of bootloading problems?
+
+What information can I collect to debug a bootloading problem?
+
+Can my Arduino have the bootloader damaged?
+
+How can I tell if my bootloader is damaged?
+
+Why else would I want to upload a new bootloader?
+
+Can I replace or upload a new bootloader with no additional equipment?
+
+How can I replace or upload a new bootloader?

Wiki/CompilingOptiboot.md

@@ -0,0 +1,54 @@
+# Introduction #
+
+You can compile Optiboot for platforms that do not have pre-existing .hex files, or you can make modifications to the source code and/or Makefile in order to implement "custom" versions of Optiboot.
+
+This will require some relatively deep knowledge of avr-gcc, Atmel AVR hardware and processor details, Makefiles, and the command line environment.  We HAVE tried to take steps to allow Optiboot to be compiled without installing a full AVR development suite.
+
+
+# Details #
+
+Optiboot is designed to be compiled with the same version of avr-gcc that is distributed with the Arduino environment: 4.3.2.  This is actually quite an old version of gcc; some effort has been made to allow the compile to procede with new versions of the compiler.  However, since Optiboot MUST compile to a total size of less than 512 bytes, it is very sensitive to changes in the way the compiler does optimizations, or the way it processes optimization options on the compile command.
+
+In all cases, Optiboot compiles directly from the command line using "make", rather than from within any IDE.  It is currently designed to used compilers installed in one of three different places:
+
+  * Local Development Environment - you have WinAVR (on Windows), CrossPack (on Mac), or an avr-gcc package (linux) installed on your system, with appropriate development tools somewhere in your path.
+  * You have Arduino installed, and are trying to compile Optiboot from its home directory within the Arduino directory structure (hardware/arduino/bootloaders/optiboot/)  The Arduino app includes a pretty complete set of compiler tools, and these can be used to compile optiboot without installing a separate toolchain. (as of Version 1.5 of the Arduino IDE, a much smaller set of tools is included, and this method doesn't work any more.)
+  * You have downloaded the Arduino Source code, which also includes (binary) copies of avr-gcc toolchains, and a source directory containing the Optiboot source code.
+
+WARNING: some targets don't compile with "make" 3.81 or 3.82 due to bug in it.  See https://github.com/Optiboot/optiboot/issues/106
+
+
+# Compile Options #
+
+The Optiboot build procedure has been set up to allow a large set of customization options.  The general format of a build command is:
+
+~~~~
+make <platform>  <options>
+~~~~
+Where <platform> is one of the named chips or boards implemented as normal targets in the makefile (ie "atmega328".) (the order may be reversed.) The implemented <options> include:
+
+  * AVR_FREQ=nnnnnn  --  Use CPU frequency as specified (default: target dependent, but usually 16000000L)
+  * BAUD_RATE=nnnnn  --  Use an alternate bitrate (default: usually 115200)
+  *
+  * LED=\<portpin\>  --  Like "LED=B5" or "LED=L5"; which LED to flash.
+  * LED\_START\_FLASHES=n  -- number of flashes to emit when the bootloader executes (default 3)  Setting this to 0 omits the LED-flashing code and saves some space.
+  * LED\_START\_ON  -- Turn on the LED when the bootloader starts.  A smaller alternative to LED_START_FLASHES.
+  * LED\_DATA\_FLASH  -- flash the LED in the data receive function as well as at bootloader startup.
+  *
+  * SOFT_UART=1  --  use a bit-banged Software Uart.  Required for chips without a HW UART.
+  * SINGLESPEED=1  -- Operate the UART in single-speed mode.
+  * UART=n  -- user UARTn instead of UART0.
+  *
+  * BIGBOOT=1 -- include extra features that cause the bootloader to grow to between 512 and 1024 bytes.
+  * SUPPORT_EEPROM=1 -- try to include EEPROM read/write support, without other BIGBOOT features.
+
+For example:
+
+~~~~
+make UART=1 LED=A7 AVR_FREQ=20000000L atmega1284
+~~~~
+Note that many of the board-level targets are implemented using a recursive invocation of make using this options.  For exmaple, the "pro20" target ends up being:
+
+~~~~
+ make atmega168 AVR_FREQ=20000000L LED_START_FLASHES=3
+~~~~

Wiki/GoodQuestions.md

@@ -0,0 +1,56 @@
+# Good Question! #
+
+Optiboot occasionally generates questions on various forums (Arduino, AVRFreaks, etc), and I thought I'd collect some of the answers here, without spending a lot of time trying to re-organize them as actual "documentation."
+
+  1. Do Arduino "sketches" require the Optiboot (or other) bootloader to be loaded on the chip?<br><br>
+ No.  While it's technically possible for a bootloader to include "support functions" used by the application section, Arduino does NOT do this.  Nor do sketches require a bootloader to have done any chip initialization.  In fact, Optiboot tries to start the application with the chip in a state as close as possible to its "reset" state.<br><br>
+
+  1. Can I put Optiboot on my Arduino MEGA2560 ?<br><br>
+  Yes, as of Optiboot v7.0<br>
+In older versions, Optiboot was limited by the "Version 1" STK500 communications protocol, which only allows up to 64kwords of flash to be programmed.  The v7.0 code uses an out-of-band "SPI Command" to set the RAMPX register.<br><br>
+ 
+  1. Why does Optiboot have its own copy of boot.h ?<br><br>
+  The copy of boot.h used by Optiboot has been modified to use "out" instructions instead of "sts."  The out instruction is shorter, but only works if the target registers in withing the first 64 IO addresses.<br>
+  As of Version 7.0, the Optiboot copy of boot.h has been renamed to boot_opt.h, defines ONLY the special "short" functions, and includes the standard \<avr/boot.h\> to pick up all the standard definitions.<br><br>
+  
+  1. What is a "Virtual Boot Partition"<br><br> 
+ VIRTUAL\_BOOT\_PARTITION is a hack for implementing a bootloader on parts that don't have "start at the bootloader address after reset" support.  So the start vector always has to be at 0, where it will be overwritten by the application's vectors.  Except the bootloader "cleverly substitutes" its own start address for the start of the application during "upload", causing the bootloader to always run first.<br><br>
+ 
+  1. Why is there an extra `BAUD_RATE * 4L` there? Why is it using 4L and 8L rather than just 4 and 8?<br><br>
+ It's doing rounding.  int(calculated\_divisor + 0.5), except since it's all integers we use algebra and multiply the 0.5 by something big enough to make it an integer.  (Hmm.  This is probably silly; I should just let it use compile-time floating point.  like `__delay_ms()`)<br><br>
+ 
+  1. What is the difference between `"__boot_page_fill_short" and "__boot_page_write_short"`?
+<br><br>
+ Flash is written a full page at a time, rather than a byte at a time.  To write a page of flash, you fill a RAM buffer in the flash controller peripheral (boot\_page\_fill), and then give a "boot\_page\_write" to actually write that buffer to the flash memory.  All together, there are three copies (buff, which is filled from the serial comm, the flash page buffer filled by page\_fill, and the flash itself.)<br><br>
+ 
+  1. What's with the "`#define rstVect (*(uint16_t*)(RAMSTART+SPM_PAGESIZE*2+4))`" ?
+<br><br>
+ These are "manually defined" variables.  Normally you'd say `"char buff[SPM_PAGESIZE]; int rstvector, wdtvector;"`  But C would want to include code to initialize those variables, which would be "too much" extra code for optiboot to fit in 512 bytes.  So instead we define buff as being where we know the first byte of RAM is and rstvetcor as the first byte after buff, and so on.<br><br>
+ 
+  1. What is RAMPZ? what is being done in the "`newAddress += newAddress`" line?
+<br><br>
+ RAMPZ is the "extra byte" of flash addressing for parts with more than 64k words.
+ <br>
+ The addition (multiply by 2) converts from (16bit) word addresses that Atmel likes to use in various place, to byte addresses used by the hardware and avr-libc in most places.
+ <br><br>
+
+  1. What are "sections" and the ".version" section in particular, and what is optiboot doing with them?
+<br><br>
+ The "section" attribute is equivalent to the .section gnu assembler directive.    http://tigcc.ticalc.org/doc/gnuasm.html#SEC119 (one source; generic.)  ".version" is an arbitrary name.
+ <br>
+ These are essentially commands that transfer information from the source code to the linker, which will then put together the various bits of information in various places in memory, based on the "linker map" (file provided by the infrastructure) and commands given to it explicitly ("-Wl,--section-start=.version=0x3ffe" in the Makefile.)  The newer code does this in C with attribute instead of using inline assembler, but it does the same thing.
+ <br><br>
+
+  1. How does Optiboot put the code and version number at the correct absolute flash addresses?
+  <br><br>
+ The output from the compiler is in relocatable "sections" that are then relocated and assigned to appropriate addresses by the linker.  The addresses used are normally determined by a "linker map" file that is part of the per-chip definitions included with the compiler, but in the case of Optiboot, they are specified explicitly in the link command using the <code> -Wl,--section-start=.text=0x3e00</code> type commands.<br><br>
+
+  1. Where did 0x3e00 come from?  I don't see that in the data sheet!
+  <br><br>
+ There are various places where the Atmel documentation uses WORD addresses for flash memory, while most of the gnu tools use BYTE addresses.  0x3e00 comes from the "boot size configuration" in the boot loader support chapter of the datasheet (where it says "0x1F00")<br><br>
+
+  1. Do I need a different version of Optiboot for the non-DIP packages like the ATmega328p-au ?
+<br><br>
+ No, the package should be irrelevant to the bootloader software.  Watch your pin connections, connect all the (multiple) power supply pins, and the same bootloader and bootloader loading procedure should work.  If it doesn't work, it is due to some factor other than Optiboot.<br><br>
+
+  

Wiki/Home.md

@@ -0,0 +1,10 @@
+Welcome to the optiboot wiki!<br>
+##Wiki pages:##
+
+* [[InstallingOnChips]] - loading Optiboot onto chips, using various tools.
+* [[CompilingOptiboot]]
+* [[HowOptibootWorks]]
+* [[AddingOptibootChipsToIde]]
+* [[GoodQuestions]] - Frequently asked technical questions
+* [[OtherVersions]] - 3rd party optiboot derivatives with interesting features.
+* [[Virtual-Boot-Partition]] - More about the Virtual Boot Partition.

Wiki/HowOptibootWorks.md

@@ -0,0 +1,44 @@
+# Introduction #
+
+Optiboot implements a small subset of the  "STK500 communications protocol" (version 1) defined by Atmel in their [Application Note AVR061](http://www.atmel.com/Images/doc2525.pdf)  In order to conserve code space, many of the protocol commands are ignored and receive "lies" rather than correct response codes, leading to the possibility that the bootloader may not operate correctly with all host-side software.  It is known to work with versions of "avrdude" supporting the "-c arduino" programmer type.
+
+Optiboot is designed to reside in the bootloader section, and chip fuses should be set appropriately for the size of optiboot (normally 256 words) (BOOTSZx) and to reset to the bootloader start address (BOOTRST)  Note that BOOTSZx values are chip-dependent, and some of the chips suppored by Optiboot have a 512word minimum bootloader size.)
+
+## Basic Operation ##
+  1. On reset, Optiboot starts and reads the reset reason from MCUSR.  For any cause other than "external reset", the application is started immediately.  Otherwise, optiboot attempts to download new application software:
+  1. The "start LED" is flashed to indicate that optiboot is running. (which pin is used, and how many times it flashes, is configurable.)
+  1. The (configurable) UART is configured and the WDT is enabled with a 1s timeout.
+  1. Optiboot attempts to read commands from the (configurable) serial port.  Valid characters will cause the WDT to be reset, and the application flash area to be programmed (hopefully.)
+  1. With no valid UART traffic, or after programming, the WDT is allowed to expire, causing the chip to reset.
+  1. Since the WDT reset is NOT an 'external reset', the application is started as in (1) - the AVR at the time the application is run has all IO registers except MCUSR and SP in their pristine, reset, state.
+
+# Details #
+## Implemented Commands ##
+The following core commands are "supported"; they actually do something useful WRT loading code via the bootloader:
+
+|Cmd Name | Value  | Description |
+|:--------|-------|:------------|
+|STK\_LOAD\_ADDRESS|0x55,'U'| Note: 16bit word address, 128kb flash max.|
+|STK\_PROG\_PAGE|0x64,'d'|  Flash only|
+|STK\_READ\_PAGE|0x74,'t'|  Flash only|
+|STK\_READ\_SIGN|0x75,'u'|  Reads compiled-in signature.|
+|STK\_LEAVE\_PROGMODE|0x51,'Q'| Starts application code via WDT reset.|
+|STK\_GET\_PARAMETER|0x41,'A'| Supports "minor SW version" and "major SW version"  Returns 3 for all other parameters.|
+
+The following commands will have their arguments correctly read, and produce in a "success" response, but they don't actually do anything:
+
+|Cmd Name | Value |
+|:------------- |:-------- |
+|STK\_UNIVERSAL|0x56, 'V'| |
+|STK\_SET\_DEVICE|0x42, 'B'| |
+|STK\_SET\_DEVICE\_EXT|0x45, 'E'| |
+
+All other commands will result in a success response if they are immediate followed by CRC\_EOP (0x20, ' ') (ie they are ignored), or a WDT reset (start applicatin) otherwise.
+
+## Space Saving Techniques ##
+In order to save space, Optiboot utilizes a couple of techniques that may be of general interest:
+
+  * The Vector table and normal startup code are omitted by using linker options "-nostdlib -nostartfiles"
+  * This requires that main() be declared with attribute OS\_main and manually placed in the .init9 section.
+  * and thus main() has to initialize the known-zero register (r1) and SP on chips that don't automatically set SP to end-of-ram.
+  * inlining of functions is carefully controlled.

Wiki/InstallingOnChips.md

@@ -0,0 +1,52 @@
+# Installing optiboot #
+
+There are two aspects to "installing optiboot."  The first problem, which is discussed here, involves getting the optiboot firmware into chips, whether the chips have an older version of a bootloader, or are completely blank.
+
+The second problem is configuring the Arduino IDE to support the optiboot-loaded chips.  This is easy if you're loading up ATmega328x chips, since any 328 chip with optiboot is essentially an Arduino Uno, and you can use the existing Uno configuration.  It is more difficult (and not yet documented) if you're adding a new chip, or putting optiboot on a chip that normally uses a different bootloader.  This is (will be) described at [[AddingOptibootChipsToIde]].
+
+Much information about burning optiboot into ATmega chips for use in Arduino can be found in the Arduino forums, especially in [this thread](http://arduino.cc/forum/index.php/topic,64105.0.html)
+
+There are about three main methods of installing optiboot on an otherwise blank AVR chip.
+
+## Installing using the Arduino IDE ##
+The Optiboot project here includes ONLY the bootloader, not any support for a chip or chip
+options in the "core" Arduino code.   It also includes bootloaders for many chips, of which only a few are likely to be of interest to any one person.  This means that while it is *possible* to "install" Optiboot in the IDE, this is no longer the preferred way to do thing.
+
+ In recent years, since the introduction of installable
+3rd party hardware in Arduino 1.6.4, open-source developers have been busy creating
+additional "boards" for the IDE that can be installed very easily.  Many of these cores
+use Optiboot, or a modified version of Optiboot, as their bootloader, and the preferred
+method of installing "XXX processor with Optiboot bootloader" is to ignore this repository
+entirely, find a core for that processor, and use the board manager to install it.
+
+Here are some of the well-known and well-used "cores" that use Optiboot:
+
+* https://github.com/MCUdude/MiniCore  (ATmega328, ATmega168, ATmega88, ATmega48 and ATmega8)
+* https://github.com/MCUdude/MightyCore  (ATmega8535, ATmega16, ATmega32, ATmega164, ATmega324, ATmega644 and ATmega1284)
+* https://github.com/MCUdude/MegaCore  (ATmega64, ATmega128, ATmega640, ATmega1280, ATmega1281, ATmega2560 and ATmega2561)
+* https://github.com/SpenceKonde/ATTinyCore  (ATtiny 841, 828, 1634, 87, 167)
+
+
+If you are using a chip that is "supported" by the Arduino team, or by some other person who has provided files, you can install optiboot (or for that matter, any other bootloader) directly from the Arduino IDE.  This usually has the following steps:
+
+  1. Install the files as directed, usually (for Arduino 1.0+) in a subdirectory of your personal sketch's ../hardware/ directory.  Note that the formats of various files (notably boards.txt) have changed with different versions of the IDE, and you'll need to make sure that the files you have been provided match the version of the IDE you are using.
+  1. Connect a device programmer to the ISP connector of the target board, or via wires to an avr chip with appropriate support hardware in a protoboard, as per the instructions associated with that programmer.  It will need to be a programmer of a type supported by the Arduino IDE in the tools/programmer Menu.  You can use a 2nd Arduino with the ArduinoISP sketch as a programmer.  The details are beyond the scope of this document, but are often discussed in the Arduino forums.
+  1. Running the Arduino IDE, select the tools/board of the target chip, and the tools/programmer of your programmer, and if necessary the tools/serial port of the programmer.
+  1. Select tools/Burn Bootloader
+
+## Installing using a specialized bootloader loader sketch ##
+There are a couple of Arduino sketches that have been written to make it easier to reprogram Optiboot (or other SW) into other Arduinos, especially in bulk.  One example is WestfW's [OptiLoader](https://github.com/WestfW/OptiLoader).  Similar programs are available from [Adafruit](https://github.com/adafruit/Standalone-Arduino-AVR-ISP-programmer) and [Nick Gammon](http://www.gammon.com.au/forum/?id=11635).  These typically contain a pre-loaded copy of some version of the bootloader for several different chips (OptiLoader supports ATmega8, ATmega168, ATmega328P, and ATmega328.)  It's very fast and easy IF you have one of the supported targets:
+
+  1. Set up an existing Arduino with an Arduino to ISP connector and load the optiLoader sketch using the standard Arduino IDE.
+  1. For each target board, connect the ISP connector and hit the reset button on the optiLoader Arduino, or use the "G" command in the Serial Monitor.  Programming the bootloader takes about 5 seconds, and reports status and information to the Arduino serial port.
+
+## Installing using the optiboot repository Makefile ##
+We might assume that you're here at the optiboot code repository because you want to use optiboot on a chip that is NOT supported by another party, but is supposed to be supported by the optiboot in general.  (An example might be the ATmega1280, which normally runs a different bootloader.)
+
+  1. Compile the appropriate binary target (ie "mega1280"), as described on the CompilingOptiboot page.
+  1. Connect a device programmer to your target as appropriate.
+  1. Edit the Makefile to make the ISPxxx variables correct for your programmer.  Make sure that there is a "target\_isp" make target defined, or create it using the existing targets as examples.
+  1. Use a command like "make mega1280\_isp" to burn the bootloader.
+  1. You can also use avrdude at the command line, manually.  Burning the bootloader is usually a two-step process:
+    * "chip erase" the target and set the fuses and lockbits to allow writing to the bootloader section of the device
+    * burn the bootloader at its defined address, and reset the lockbits to prevent accidental overwriting of the bootloader section.

Wiki/OtherVersions.md

@@ -0,0 +1,3 @@
+A number of people have modified some version of Optiboot to support additional features or communications channels, where I have decided for one reason or another NOT to merge those changes back into the main Optiboot source.  Nevertheless, they're worth referencing here...
+
+<http://sowerbutts.com/optiboot-w5100/> Boot over TCP using Wiznet W5100 chip.  As small as 1K.

Wiki/Virtual-Boot-Partition.md

@@ -0,0 +1,44 @@
+# Virtual Boot Partition
+
+  1. What is a "Virtual Boot Partition"?
+ 
+ VIRTUAL\_BOOT\_PARTITION (VBP in short) is a hack for implementing a bootloader on parts that don't have "start at the bootloader address after reset" support. Sometimes it could be useful for normal chips when changing or messing with fuses is impossible or not desired.
+
+  1. How it works?
+ 
+ During programming bootloader "cleverly substitutes" start vector of application (located at address 0) by jump to bootloader. This way bootloader is always run after reset.
+ 
+  1. But how bootloader knows where application starts?
+
+ Bootloader assumes that start of application is typical vector table generated by most compilers. When Optiboot change start vector, it saves original jump to another free vector. Typically it uses SPM_RDY vector, or WDT if SPM_RDY is unavailable.
+ 
+  1. I have chip without SPM_RDY and I need to use WDR vector in my code.
+ 
+ It's possible to assign arbitrary vector using additional option to CFLAGS: `-Dsave_vect_num=xxx` where xxx could be name of vector like `EE_RDY_vect_num` (see virboot8 target in Makefile) or even just number (see attiny84 target in Makefile.extras). In fact, any number could be used, even outside vector table. There is only one limitation: it **MUST** be located in first flash page!
+ 
+  1. I don't use vector table. Can I use it anyway?
+ 
+ Yes, as long as first instruction is **jmp** on chips with more than 8KB memory or **rjmp** on smaller memory devices. You must also provide another jump to store old jump by Optiboot.
+  
+  It could be done for example by adding `-Dsave_vect_num=1` to CFLAGS during compiling bootloader, and making beginning of application like this:
+
+  ~~~~
+    rjmp app
+    rjmp nowhere
+  app:
+    ... ;your code here
+  ~~~~
+
+  1. I want to add VBP to chip XXX
+
+ Check Makefile targets **virboot8**, **virboot328** or **attiny84** for examples.
+ 
+ There are 2 things required:
+ * add `-DVIRTUAL_BOOT_PARTITION` to CFLAGS
+ * adjust (decrease) address in **.text** part of LDSECTIONS (for example in `--section-start=.text=0x1c00`) to fit larger bootloader in memory
+
+  1. Any downsides of this feature?
+
+ Sadly, there are 2 of them:
+ * Bootloader code is larger and doesn't fit in 512B
+ * It requres one unused vector to store original jump to application. And you must be sure that this vector will be unused by applications loaded by Optiboot with VBP enabled.

Wiki/github-issue-labels

@@ -0,0 +1,29 @@
+Explanations for possibly mysterious lables used on Optiboot github "issues."
+
+Component-Docs  - requires a fix in the documentation only
+Component-Makefiles - requires a change to the makefiles only
+Component-Scripts - changes to the scripts only
+Discussion - an "issue" that has significant "discussion" involved; may not be an actual bug.
+Duplicate
+help wanted - "official maintainers" don't have the parts or the interest.  A request for someone in the community to provide a patch/pull request/etc.
+Invalid - the bug is reported in error, or determined not to exist.
+Maintainability - affects the ease of maintenance of the program.
+Not-our-issue - the actual problem is determined to lie outside of optiboot itself.
+OpSys-Linux
+OpSys-OSX
+OpSys-Windows
+Partly Done - come code has been added/merged, but there is more to do.
+Priority-Critical
+Priority-High
+Priority-Low
+Priority-Medium
+Question - more of a
+Regression - something that used to work correctly has broken
+Superseded - was a bug at one time, but is no longer present because of other changes.
+Type-Defect
+Type-Enhancement
+Type-newChip - request for a new chip; usually involves Makefile and pin_defs.h, but not actual program logic.
+Type-Other
+Type-Patch
+wontfix - describes a real problem that can't be fixed, or won't be fixed because we think it is outside the scope of Optiboot.
+

optiboot/boards-1.6.txt

@@ -54,7 +54,7 @@ optiboot28.menu.cpu.atmega328p.upload.maximum_size=32256
 optiboot28.menu.cpu.atmega328p.upload.maximum_data_size=2048
 
 optiboot28.menu.cpu.atmega328p.bootloader.high_fuses=0xDE
-optiboot28.menu.cpu.atmega328p.bootloader.extended_fuses=0x05
+optiboot28.menu.cpu.atmega328p.bootloader.extended_fuses=0xFD
 optiboot28.menu.cpu.atmega328p.bootloader.file=optiboot/optiboot_atmega328.hex
 
 optiboot28.menu.cpu.atmega328p.build.mcu=atmega328p
@@ -66,7 +66,7 @@ optiboot28.menu.cpu.atmega328.upload.maximum_size=32256
 optiboot28.menu.cpu.atmega328.upload.maximum_data_size=2048
 
 optiboot28.menu.cpu.atmega328.bootloader.high_fuses=0xDE
-optiboot28.menu.cpu.atmega328.bootloader.extended_fuses=0x05
+optiboot28.menu.cpu.atmega328.bootloader.extended_fuses=0xFD
 optiboot28.menu.cpu.atmega328.bootloader.file=optiboot/optiboot_atmega328.hex
 # lie!  Arduino wise, these are compatible
 optiboot28.menu.cpu.atmega328.build.mcu=atmega328p
@@ -171,7 +171,7 @@ optiboot32.menu.cpu.atmega328p.upload.maximum_size=32256
 optiboot32.menu.cpu.atmega328p.upload.maximum_data_size=2048
 
 optiboot32.menu.cpu.atmega328p.bootloader.high_fuses=0xDE
-optiboot32.menu.cpu.atmega328p.bootloader.extended_fuses=0x05
+optiboot32.menu.cpu.atmega328p.bootloader.extended_fuses=0xFD
 optiboot32.menu.cpu.atmega328p.bootloader.file=optiboot/optiboot_atmega328.hex
 
 optiboot32.menu.cpu.atmega328p.build.mcu=atmega328p
@@ -183,7 +183,7 @@ optiboot32.menu.cpu.atmega328.upload.maximum_size=32256
 optiboot32.menu.cpu.atmega328.upload.maximum_data_size=2048
 
 optiboot32.menu.cpu.atmega328.bootloader.high_fuses=0xDE
-optiboot32.menu.cpu.atmega328.bootloader.extended_fuses=0x05
+optiboot32.menu.cpu.atmega328.bootloader.extended_fuses=0xFD
 optiboot32.menu.cpu.atmega328.bootloader.file=optiboot/optiboot_atmega328.hex
 # lie!  Arduino wise, these are compatible
 optiboot32.menu.cpu.atmega328.build.mcu=atmega328p
@@ -241,7 +241,7 @@ optiboot1280.upload.maximum_data_size=8192
 
 optiboot1280.bootloader.low_fuses=0xFF
 optiboot1280.bootloader.high_fuses=0xDE
-optiboot1280.bootloader.extended_fuses=0x05
+optiboot1280.bootloader.extended_fuses=0xFD
 optiboot1280.bootloader.file=optiboot/optiboot_atmega1280.hex
 
 optiboot1280.build.mcu=atmega1280
@@ -271,7 +271,7 @@ optiboot1284.upload.maximum_data_size=16384
 # Select full swing crystal oscillator (F7 rather than FF)
 optiboot1284.bootloader.low_fuses=0xF7
 optiboot1284.bootloader.high_fuses=0xDE
-optiboot1284.bootloader.extended_fuses=0x05
+optiboot1284.bootloader.extended_fuses=0xFD
 optiboot1284.bootloader.file=optiboot/optiboot_atmega1284p.hex
 
 optiboot1284.build.mcu=atmega1284p