What is the best method to deploy OpenSK on makerdiary nRF52840 USB dongle without loosing boot loader?

[alishir]

Hello,
As you know makerdiary nRF52840 USB dongle ships with UF2 boot loader that enables deploying/upgrading new firmware without using any programmer. But according to the pull request #186 deploying current version of OpenSK will erase the boot loader. So my question is what is the best method to deploy the OpenSK without loosing boot loader.

I know that this approach have some side effects and security risks, but currently I want to do some development and do some tests.

[jmichelp]

It should be safe to flash the dongle over DFU. I've done it and it works if the dongle is new.
The risk is if another firmware was previously used on the dongle and was using a different configuration than OpenSK. Then it may result is erasing the 2 registers.

The bootloader (both the Nordic one and the UF2 one) use code at the beginning of the flash called MBR and this is safe with regards to TockOS/OpenSK. But they also use storage for settings in the flash, which OpenSK doesn't know about. And after using the dongle for a while, it might be possible that this settings area got overwritten by OpenSK. That's why the PR isn't merged yet. We need to analyze the bootloader, the settings, and the layout of the flash to find a reliable solution that removes that risk and ensures that OpenSK firmware can be safely upgraded.

[coelner]

To understand that right:
./deploy.py --board=nrf52840_dongle_dfu --opensk --programmer=none will generate a DFU compatible hex file, which can be flashed with the nrf programmer?
In my case this works so far (for a regular dongle). The _dfu board selection differs at the kernel address, this is needed because of what?

The programmer nordicdfu currently does not work because python3.9 is incompatible. Is this line needed to build dfu packages which can be used by nrfutil instead of nrf connect and the corresponding programmer?
./nrfutil-linux pkg generate --hw-version=52 --sd-req=0 --application-version=1 --application=/home/user/OpenSK/target/nrf52840_dongle_dfu_merged.hex /home/user/OpenSK/target/nrf52840_dongle_dfu_merged.zip

[jmichelp]

To understand that right:
./deploy.py --board=nrf52840_dongle_dfu --opensk --programmer=none will generate a DFU compatible hex file, which can be flashed with the nrf programmer?

This will generate a IntelHEX file. Which then can be turned into a DFU package using Nordic tools

In my case this works so far (for a regular dongle). The _dfu board selection differs at the kernel address, this is needed because of what?

Between flash address 0x0000 and 0x1000 is the DFU bootloader. Therefore to keep it, we need to offset Tock kernel (and also the interrupt vector table but the kernel will take care of it).

The programmer nordicdfu currently does not work because python3.9 is incompatible. Is this line needed to build dfu packages which can be used by nrfutil instead of nrf connect and the corresponding programmer?
./nrfutil-linux pkg generate --hw-version=52 --sd-req=0 --application-version=1 --application=/home/user/OpenSK/target/nrf52840_dongle_dfu_merged.hex /home/user/OpenSK/target/nrf52840_dongle_dfu_merged.zip

Well, it works for me. I'm using python3.9 and I have nrfutil installed.
And on Pypi, it's also listed as python 3.9 compatible since August: https://pypi.org/project/nrfutil/
Have you tried running: pip3 install --upgrade nrfutil ?
But otherwise, yes, your command line seems correct.

[coelner]

The aur package was fixed yesterday, my fault.
Ok, the programmer app from nrf connect somehow converts it on the fly and flashes it. the DFU bootloader seems to be intact.

[rony-vargas]

I had the previous mkd UF2 firmware for OpenSK and then I flashed the one I built with the latest code from this repo, now I can't access the UF2 again.
The key is apparently working fine, I did some tests registering it and it works, it is just the UF2, so I won't be able to update it again.

[kaczmarczyck]

The missing documentation problem should be addressed in #414. It might actually be even easier, and I opened #411 to update the steps to a simple deploy once we evaluated if it's save or might still have negative side effects.