# 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.