Hi Caleb
The syntax is described at
https://www.utasker.com/forum/index.php?topic=1445.0Specifically to this case
0x10000[0x100-FALLBACK_LD]which comes from
uTaskerCombine Objects/uTaskerFallbackLoaderImage_%iMX_RT%.bin "Objects/uTaskerSerialLoaderUpload_%iMX_RT%.bin" 0x10000[0x100-FALLBACK_LD] Objects/uTaskerBootComplete_%iMX_RT%.bin Objects/uTaskerBootComplete_%iMX_RT%.hexand expands to (in the case of
iMX_RT1062)uTaskerCombine Objects/uTaskerFallbackLoaderImage_iMX_RT1062.bin "Objects/uTaskerSerialLoaderUpload_iMX_RT1062.bin" 0x10000[0x100-FALLBACK_LD] Objects/uTaskerBootComplete_iMX_RT1062.bin Objects/uTaskerBootComplete_iMX_RT1062.hexit is taking the first file (the fall-back loader image, which was already combined with the boot loader) and adds on the binary "
Objects/uTaskerSerialLoaderUpload_iMX_RT1062.bin", the serial loader. The 0x10000 tells it to add it on at the address 0x10000, meaning that it will be padded with 0xff between the two binary images to produce one file.
[0x100-FALLBAKK_LD] means that it should additionally add 0x100 bytes of space (so the second is in fact at address at 0x10100 and this 0x100 bytes of space should be filled with a file object corresponding to the second file "
uTaskerSerialLoaderUpload_iMX_RT1062.bin" and the disk volume in the file object should be called "
FALLBACK_LD".
The result is that when the serial loader runs and acts as a USB-MSD device a disk appears with the volume name "FALLBACK_LD" and it has a file on it called "
uTaskerSerialLoaderUpload_iMX_RT1062.bin" with its original date, time and size.
Without this option the combined image would not be able to be displayed in such a way since its file name and other details would not be known.
This file object is only used by the "Fall-back" loader and allows the present serial loader to be deleted (resulting in a blank disk). Then the original (or new) serial loader binary could be uploaded again and the host would create the same file object in the process so that the file's information is visible again. Therefore this option is emulating that the serial loader in the combined binary has been added by a host in an equivalent manner.
You will see that the application is subsequently added using the same utility but with a different disk volume name (so that it is clear that the serial loader is running and not the fall-back loader) and the file object added corresponds to the application binary that is being added.
The addresses are given by the loader concept layout and so should not normally be changed (unless the layout is adjusted for a certain reason in the code) but the disk volume names can be changed (limited to 11 characters I believe by FAT).
Therefore the sequence of combining the boot loader, fall-back loader, serial loader and application results in a single binary image with two file objects so that the full details of the original (and subsequently updateable) files can be visualised via USB-MSD. The result is a single file that can be loaded in a production environment rather than needing to start with the fall-back loader installed, add the serial loader and then add the application. Since the automation is so fast it is performed at every build so that this is always ready (there are also intermediate versions - boot+fall-back, boot+fall-back+serial if ever these are needed for testing and such).
Regards
Mark
