Hi Folks,

I'm considering making a boot-loader with the listed properties. I'd appreciate some thoughts, links if something similar has been done already or any ideas in general.  Just want to have a conversation going around the topic.
Features:

1. Open source: It's silly people are writing from scratch, paying for this or bricking their units cause it doesn't have a boot-loader. 
2. Secure: Allow for a user selected security algorithm to authorize the sender and a user selected code checking algorithm (CRC check). 
3. Generic: Ideally it needs to be usable on any platform. Set up callback for device initialization, flash reading and writing, authorization algorithm/public key and the code checking algorithm. 
4. CAN based: needs to be useful in an automotive setting.

I don't want to sound negative, but I think it's not going to be easy, to say the least. You need to cater for too many situations. 

Simple thing: on some systems you have enough FLASH to store two images, so you can load the new image, start it and if it fails (yes, it can happen, despite all the checks - faulty images occasionally get released), reset and fall back to the old one. However, on a system which has only one FLASH, that's not possible and you need an algorithm that can load the new image, see if that works and if it does not, re-load the previous image.

Then you have the problem that to run on every system, as you pointed out, you need to have a call-back for everything. So at the end of the day, the user must write their initialisation, authentication, crypto, FLASH access and of course CAN routines. Which is about 85% of the bootloader code. 

Also, on a low-end system you can't really do much authentication. Running 2048 bit RSA on a Cortex-M3 clocked at 60+ MHz is entirely feasible, if you have enough FLASH for the bootloader to contain a natural number library (~8-10KB). Now on a Cortex-M0 you can forget it, because you don't have 32x32->64 multiplication (as an instruction, you can of course build it from ~40 M0 instructions), plus half the registers can only be accessed by jumping through hoops. So while you can implement RSA on an M0, it will be so slow that it is all but useless.

Then you have the issue of the CAN bus itself. You can't just willy-nilly send CAN packets without knowing what CAN protocol the system is using. There are several competing standards - if you are lucky enough and the system does not use some in-house proprietary format. In any case, your bootloader needs to conform to, or at least not to interfere with, whatever protocol is sitting on top of the bare CAN packet layer. 

The idea is noble, but I think there will be many, many hurdles you'll need to jump over.

'Generic' and 'bootloader' are not compatible terms.  All the bootloaders I've created had to be tailored to specific chip architectures and memory organizations.  It would be hellish to support more than one platform and to stay current with evolving ones.

Wrt security, you do not need the complexities of asymmetric crypto if you are willing to hardcode a symmetric key into the bootloader and disable hw/sw debug.  This isn't advisable for critical systems where hackers with enough incentive can break into and inspect chip internals.  Some systems do purport to have secure symmetric key storage (ie: LPC43Sxx).

Wrt CAN, the segmented frames of the fw image can be transferred using a transport layer like ISO 15765 in combination with a RAM buffer corresponding to flash page size.  It will be a fair amount of work to implement this as well as the in-circuit-programming, handshaking, validation, etc.

I would also suggest placing version info at fixed linker locations in the fw so that the bootloader can know the version of stored images - something also that defies 'generic'.