Family ID proposal

[ladyada]

yah - i think its probably a good idea! we'd have to update the bootloaders but at least this way we'd just have the UF2 reject rather than reboot and hang instantly

[mmoskal]

Current bootloader would accept files with family Id, so we can update MakeCode to embed the Id. And we would change the bootloader to accept files with the right family id or none at all so we are backwards compatible with existing uf2 files.

I guess we could make the bootloader blink angrily when it gets wrong id.

[ladyada]

S.O.S. :)

On 6/25/2018 2:41 PM, Michał Moskal wrote:

Current bootloader would accept files with family Id, so we can update MakeCode to embed the Id. And we would change the bootloader to accept files with the right family id or none at all so we are backwards compatible with existing uf2 files.

I guess we could make the bootloader blink angrily when it gets wrong id.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Microsoft/uf2/pull/6#issuecomment-400054075, or mute the thread https://github.com/notifications/unsubscribe-auth/ABKG0WK1bwI45NIrOslIg8d4syfD9ZRkks5uAS72gaJpZM4U2mIS.

[hathach]

my two cents, I think we should have an uint32_t for family id, and uin32_t for firmware_version (optional) in case people decide to modify bootloader to prohibit a downgrade, or use that to upgrade to only to compatible firmware (same MSB byte or something).

both family id and firmware_version are best to place right before the magicEnd !?!

[mmoskal]

On very small devices you don't have enough memory to buffer entire block (eg interface chip on Uno has 0.5k of which you're already using some), so I would rather have the family Id in front.

For versions then I guess we can add a flag saying it's present and place it at the end

[hathach]

ah right, it could be trouble if the chip couldn't hold the whole 512 bytes. In that case, the family ID may be placed at offset 28, the specs say filesize or reserved. We could have an flag bit to to indicate that these 4 bytes has family meaning, otherwise back to the filesize/reserve.

[mmoskal]

right, this is exactly what it says in the PR ;)

[hathach]

@mmoskal superb, sorry to miss that.

[mmoskal]

I think if people create incompatible version of the firmware, they can just come up with an alternative familyID for whatever they are doing. Using 32 bits the probability of collision is very low.

[hathach]

Agreed, that is perfect. Glad you merged the PR, I will pull and update in our repo.