You're obviously worried about the software, not the hardware, which can only be protected with the use of ASICs, FPGA, or some other more obscure solutions.
Be careful from whom you accept a bootloader, it might come from those you want to avoid 
Joking aside, maybe you should write your own (it's not that hard), or at least add to one of the publicly available ones the protection features you expect, yourself (so only you know about them).
I would consider using these three measures of software protection the absolute minimum:
1. Encryption (which should never be considered 100% safe, which is why you will need the next two).
2. Make the distributed portion of the software only a percentage (preferably less than half) of the total code needed for the application. For example, make the bootloader include all/most common library functions, or RTOS, if one is used (provided this code is well tested so it won't likely need upgrading). In case encryption is compromised, the enemy will only get an incomplete application, the rest of it being safely hidden in the bootloader.
3. CRC verification. Foreign files cannot be loaded or executed. Even if the CRC algorithm is open,the included range(s), the CRC storage location, and possible extra transformations (e.g.., XORing with a number only you know) cannot be known by anyone else, and make it practically impossible to bypass. Without CRC control, if encryption is ever broken, it will allow loading a small 'spy' app into your device to extract the whole memory contents.
If using assembly language, you can write code in a way that it becomes harder to disassemble by using mixed code/data in a way that a dissassembler will not be able to automatically reproduce, but extensive manual labor will be required.
The idea with all this is that anything that makes unauthorized copying more expensive is good to have. If the copying effort costs more than redesigning the product from scatch, you've won.
