Updated mcuboot and README to reflect secondary_bd changes

Author: AGlass0fMilk

README.md

@@ -31,14 +31,12 @@ Care should be exercised when configuring the bootable application to ensure the
 
 The **"secondary"** memory region is provided by you. Typically this is an external flash chip used for bulk data and firmware update storage.
 
-In this example, the secondary memory region is initialized to the target's default block device instance in the following line of `flash_map.cpp` below:
+By default, the secondary memory region is provided by the `mbed::BlockDevice::get_default_instance()` API. This functionality can be overridden by redefining the weak function declared in `secondary_bd.h`:
 
 ```
-mbed::BlockDevice* mcuboot_secondary_bd = mbed::BlockDevice
+mbed::BlockDevice* get_secondary_bd(void);
 ```
 
-The symbol, `mcuboot_secondary_bd`, is an `extern` expected to be defined when `mcuboot.bootloader-build` is 1 (ie: you are building mcuboot as a bootloader and not an application library).
-
 Since the Mbed-OS mcuboot port uses Mbed's `BlockDevice` API, there is a lot of flexibility when providing the secondary memory region. For example, you can use a `FlashIAPBlockDevice` if your application is small enough to fit two copies in the internal flash. If you also use your external flash chip for data storage you can simply wrap the whole `BlockDevice` object in a `SlicingBlockDevice` to give mcuboot access to a certain region of your external flash.
 
 The Mbed-OS mcuboot port also has an additional function that the application can define if needed: `void mbed_mcuboot_user_init(void)`. This is provided as a `weak` symbol so the application can perform any necessary initialization before the rest of the boot process begins.

mcuboot.lib

@@ -1 +1 @@
-https://github.com/AGlass0fMilk/mcuboot/#d3ebeac565b822ba52653d1065eb6616652eee10
+https://github.com/AGlass0fMilk/mcuboot/#9adc5c15e05691c8bcfc7d617bbc67b5e9ef57ba