• Size: Bootloader code size including small table at top end
• Usage: How many bytes of flash are needed, ie, HW boot section or a multiple of the page size
• Version: For example, u7.6 is an urboot version, o5.2 is an optiboot version
• Features:
  • w bootloader provides pgm_write_page(sram, flash) for the application at FLASHEND-4+1
  • e EEPROM read/write support
  • U checks whether flash pages need writing before doing so
  • s uses skeleton of STK500v1 protocol (deprecated); -c urclock and -c arduino both work
  • d dual boot (over-the-air programming from external SPI flash)
  • h hardware boot section: make sure fuses are set for reset to jump to boot section
  • j vector bootloader: applications need to be patched externally, eg, using avrdude -c urclock
  • p bootloader protects itself from being overwritten
  • P vector bootloader only: protects itself and reset vector from being overwritten
  • r preserves reset flags for the application in the register R2
  • a autobaud detection (f_cpu/8n using discrete divisors, n = 1, 2, ..., 256)
  • c bootloader provides chip erase functionality (recommended for large MCUs)
  • . unable to tell from .hex file whether this feature is present
  • - corresponding feature not present
• Hex file: often qualified by the MCU name and/or configuration
  • swio software I/O (not UART)
  • led9 toggles an LED on, in this example, Arduino pin 9
  • cs8 uses Arduino pin 8 as chip select of external SPI flash memory for dual boot
  • fp9 for debugging the bootloader uses, eg, Arduino pin 9 to swing a signal of low frequency, eg, 50 Hz
  • min most feature-rich bootloader for smallest achievable flash usage

Note that the bootloaders with a part name, eg, atmega8_a.hex are usually template bootloaders: instead of the opcodes for toggling specific LEDs or pulling a specific CS line for external SPI flash memory they hold generic nops of the sort mov rx,rx. This means they can be replaced on the fly just before burning the bootloader; thus specifying the LED, CS or RX/TX pins (for software I/O) can be done at burn time w/o compiling the bootloader. Therefore atmega8_a.hex won't operate blinkenlights, but has placeholder code to insert the right opcodes for doing so. In contrast to this, bootloaders with a board name, eg, jeenode will normally have been compiled for that board, ie, the bootloader uses the LED and/or CS for external SPI flash memory as is on that board.