Add flash protection for bootloader/SD

[microbuilder]

By default, we should perhaps protect the bootloader and SD section of memory from being overwritten, since users can (and will) do stupid things with the OTA updater.

The Arduino IDE is safe without a JLink (etc.) connected, but you can update the bootloader and SD OTA, which I think we should only make possible once you have done a secret handshake like running a sketch the 'unprotects' those sections, making the user responsible for their actions.

There are mechanism to protect certain parts of flash, presumably for the nRF52 as well: https://devzone.nordicsemi.com/question/16414/protect-bootloader-from-overwriteerase/

[hathach]

good point, basically, we will force some extra steps to perform SD or SD+bootloader upgrade either by serial/ota

[microbuilder]

Yeah, I think we should have two sketches ... one to 'unlock' the flash sections, and one to 'lock' them. We can compiled those down to .hex files and use them in the production tester, and when users want to update the SD and/or bootloader, they will need to run the unlock sketch so that it's clear they are doing something risky.

[hathach]

two sketch is a bit over protected. I am thinking to check some magic number, which is unique for each SD + bootloader combo --> user need to manually change it before packing it into zip package file. That could be check by the booltoader. Sort of unlock code, in general, we won't document it well, only ask when user asks perhaps :D

[microbuilder]

I think just locking and unlocking the appropriate pages is better using the standard SD calls, and we'll get a standard error back from the bootloader, and I can just add a sample sketch here like we do to toggle the NFC pins between GPIO mode and NFC mode, which requires writing to the config data: https://github.com/adafruit/Adafruit_nRF52_Arduino/blob/master/libraries/AdafruitFeather52Examples/Hardware/nfc_to_gpio/nfc_to_gpio.ino

This will also be less work to maintain since during production we just need to build those sample sketches to get a .hex file, and we can include that as part of the production process.

[microbuilder]

The main risk here is only for OTA updates, and to be honest most people won't be doing OTA updates since you can control everything from the Arduino IDE. OTA updates should only happen during a SD update, which should be rare since it's fairly stable at this point.

In that respect, I'm OK with lock and unlock sketches even if it's some work for end users, but I prefer something we can easily update if anything changes, and just recompile it.

[hathach]

The SD call with protect won't work with the two sketches scenario since it relies on the BLOCK PROTECT register which is clear upon reset, which our board needs to upload a sketch.

I think when starting up, SD already protect itself, that is why we need SD call to access the register (since it is used by SD as well). I may misunderstood your point though, but we want to protect user from Flashing an incorrect SoftDevice + Bootloader package (let's say from Nordic SDK) or even an stupid binary somewhere right ??

[microbuilder]

Yes. I'm afraid users will sent the wrong bootloader or SD, and then we need a JLink to debrick them, and it becomes a support headache even if the fault is essentially on the end users side but to avoid having to explain that, it's better to prevent people from doing stupid things in the first place. Thanks for the note on the SD BLOCK PROTECT, though. I'll have a look in the documentation at that.

[microbuilder]

I don't care what they do with the user app, BTW, since that's easy to change ... but if they corrupt the bootloader or SD, it becomes a product return or unhappy customer (even if it was their fault but they may not see it that way).

[microbuilder]

Lets move this over to email to avoid bothering everything email alerts with the discussion :P

[hathach]

yup

[microbuilder]

Apps will now be rejected OTA unless they target the right chip and SD.