Combining a bootloader and user program into single flash-able binary
You've inaccurately specified the bootloader address, and that's important.  

If the regions the bootloader and application programs would occupy are contiguous with at most a little padding to allow growth of future bootloader versions, then you can simply concatenate the binaries (with padding) and produce a single flat binary.  If both are going into the same user flash bank, that would typically be the case.   But if the regions are distcontinuous, then you'd need a format like an Intel Hex or s-record file or a .elf which can accommodate jumps to various addresses.

With a GCC style toolchain (as Atmel themselves now offer for their ARM parts) you can typically use the arm-none-eabi-objcopy (middle identification may vary) to manipulate and combine .elf, hex, and flat binary files.  For simple cases you can also combine flat binaries with cat (if no padding is needed) or dd (if it is), and combine .hex files with cat or a scriptable text editor, possibly after stripping off any whole-file metadata.

For a typical program including the bootloader you are looking at, you'll find the actual memory assignments in the linker script (.ld) file, and you can find the usage of objcopy to produce a flat binary in the project Makefile.

Note that generally you want to build and link each of the bootloader and the application program as independent projects; you don't want the linker trying to share anything between them, except possibly for things you define at fixed dispatch addresses; otherwise it becomes near impossible to change one without requiring a rebuild of the other, which largely defeats the purpose of having a bootloader.   When I do bootloaders for ARM-based systems, I typically just have the bootloader parse the vector table at the start of the application program, mimicking what the hardware itself does on startup; that also makes it possible to simply copy the application program's vector table to the hardware start address and have the chip start directly into the application without a bootloader, which can simplify debugging.