Implications of changing bootloader size

Question

Hi, 
 This is somewhat open ended question, but I wanted to know the implications of modifying the default bootloader (one that comes with SDK v6.1.0) upfront, so that the implementation would be easier for me. 
 Environment: 
 
 nRF51822QFAA (256kB flash) 
 SDK v6.1.0 
 SoftDevice v7.1.0 
 Application size (app.hex file about
84kB, app.bin about 31kB) 
 KEIL uVision 5 development
environment 
 Current bootloader size: 14kB 
 DFU OTA mode: Dual 
 Custom Board with nRF51822QFAA 
 
 1: The default memory layout configuration (0x3C000, 0x40000) of Bootloader reserves 16kB of memory, however with intended modifications, I think bootloader size would reach upto 24kB or so. As of now, the intentions is to program application f/w from the stored f/w in on-board external flash memory connected over SPI. I think it should be straight forward to do appropriate changes in bootloader to pick up the application f/w from the external flash memory and program nRF5182QFAA. This would lead to increase in bootloaer size (may cross 16kB current barrier). Since there is no headroom ( 0x40000 is the last accessible address), I need to snatch some memory from application and update the bootloader start address accordingly. Please let me know if I should take into consideration some more things. 
 2: Can I use .bin file instead (generated using fromelf.exe) for application firmware upgrade by using the technique as mentioned in item 1 above.( I know that the DFU-OTA applications such as Nordic nRFToolbox and MCP for Android cellphone require a .hex file and In past I've been able to successfully update the application f/w with .hex file). 
 Thanks.

Hung Bui · Accepted Answer

@sidekick: 
 
 If you think your bootloader gonna expand, you can simply move the start address from the current address 0x3c000 down a little bit to give some headroom for future development.
But if you don't plan to have BLE or UART DFU, I don't think your bootloader's size would be much bigger than our bootloader (unless you have extra features such as encryption or smth). Make sure you remove the BLE/UART code when you implement yours. 
 
 I don't think anything else need to be taken care of except for the change of the start address of the bootloader. You can have a look here , where we change the optimization level of the bootloader and the size got much bigger. 
 2 . Yes you can use binary file. What transmitted over the air is actually binary image file. So even if you give hex file to the DFU master, it will convert to binary. Most of our DFU master now accept both .hex and .bin file.