Using GnuK with DFU bootloader

[Peter Lebbing]

Hi Gniibe,

I was trying to make it so that you can upload GnuK to the Maple Mini
with a DFU bootloader. Here's what happened :-).

First of all, uploading by DFU
1) does not protect the flash from reading
2) keeps the bootloader intact, through which you can also read out the
flash.

So my goal is to upload GnuK through DFU and then upload another GnuK
through reGNUal, which would kill the DFU and engage read lockout.

There is already some DFU code in GnuK, I tried to leverage that.

One
~~~

The default Maple Mini DFU puts uploaded code at 0x8005000. This is too
high for GnuK (at least, without changes, it does not fit). But
STM32duino-bootloader[1] is small; it loads code at 0x8002000. So I
changed ORIGIN in gnuk/src/configure to match.

Two
~~~

It appears the DFU-code in GnuK is faulty?

First, `func` (main.c:412 [2]) is loaded from new_vector[9] while the
DFU bootloader is still there, picking up data from the bootloader (at
0x8000024). It should only be loaded later, when SYS is copied to the
first sectors.

Second, the first 4 KiB is erased, but not written with SYS.
flash_write() refuses to overwrite the first 4 KiB, leaving it empty
instead of filled with SYS.

I tried to fix these things in commit 2e2d68d, which you can find at my
GitLab: [3].

I used a copy of flash_write() with the check removed. This
should actually still be portable, since flash_program_halfword() is
also in SYS? Anyway, it'll do for now for sure.

PLEASE NOTE: upgrade_by_password.py has been modified to not lock memory
readout. After all, that is slightly annoying when debugging ;-).

Three
~~~~~

It still does not work. Why? Simple. We have SYS copied from 0x8002000
to 0x8000000, including all the pointers. So the vector at 0x8000024
(flash_erase_all_and_exec) is still pointing to the routine of the SYS
at 0x8002000, and when called, it will soon erase itself. Not so much
self-modifying as self-destroying code, and the processor faults.

Four
~~~~

My current attempt is to have the GnuK that has been loaded via DFU not
do any erasing or relocating. Instead, have a custom reGNUal erase the
whole flash including the first 4KiB, and then have it program the whole
flash including the first 4 KiB, with a bog-standard GnuK without DFU
support.

This doesn't work yet, and I really need to be doing other stuff now,
so, to be continued.

What do you make of this? Does the DFU+reGNUal work on other boards; I
cannot see how it could?

Cheers,

Peter.

[1] <https://github.com/rogerclarkmelbourne/STM32duino-bootloader>
[2] <https://gitlab.com/DigitalBrains1/gnuk/blob/master/src/main.c#L412>
[3] <https://gitlab.com/DigitalBrains1/gnuk/tree/dfu>

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20181212/5efeee20/attachment.sig>