The warnings are caused by a huge gap in memory between the vectors sections and the main sections for the executable file.
When the objcopy program encounters discontinued memory sections, it automatically pads them with 0s. In the above case, since the offset is so large, the program truncates the output ".bin" file and issues the warning messages. Otherwise, the output file will be extremely large (imagine the size in bytes from 0x00 to 0x86000000 = 2 GB!).
To work around this problem, you can use the following commands to prevent the padding in the discontinued memory sections.
mb-objcopy -O binary -j .vectors.reset -j .vectors.sw_exception -j .vectors.interrupt -j .vectors.hw_exception ./spi_user_app/executable.elf ./flash_burn/spi_user_app1.b
mb-objcopy -O binary -R .vectors.reset -R .vectors.sw_exception -R .vectors.interrupt -R .vectors.hw_exception ./spi_user_app/executable.elf ./flash_burn/spi_user_app2.b
cat ./flash_burn/spi_user_app1.b >> ./flash_burn/spi_user_app2.b
These commands generate the bin file individually for different sections (with only and without the vector sections) and concatenates them together afterward.
This Answer Record also applies when you want to reduce the size of the resulting bin file from mb-objcopy and store the bin in Flash. This bin file cannot be run from Flash, a bootloader will need to be used to copy the bin file from Flash into DDR.
Note: It has been seen that some Xilkernel applications converted into bin format were not executing once bootloaded into DDR. To workaround this issue the catcommand was not run.
Instead, when generating the MCS file in impact (or from command line) the two bin files where past in separately in concatenation. So, for example if the bin file containing the vector space was placed at an SPI offset of b400000, then the other sections would be placed at b400000 + vector space (400hex). To do this from command line will look like:
promgen -spi -w -p mcs -u 0 download.bit -data_file up b40000 app1.bin -data_file up b40400 app2.bin