Using GnuK with DFU bootloader

NIIBE Yutaka gniibe at fsij.org
Fri Dec 21 04:02:20 CET 2018


Hello, Peter,

I cherry picked your changes into master, writing ChangeLog entries.

Peter Lebbing <peter at digitalbrains.com> wrote:
> I actually did quite a lot of testing.

Thanks a lot for your intensive testing.

I have a little concern here.

diff --git a/src/main.c b/src/main.c
index a8c80b6..04a8c9e 100644
--- a/src/main.c
+++ b/src/main.c
@@ -141,7 +141,7 @@ device_initialize_once (void)
 
         addr = ORIGIN_REAL + 0x1000;
         if (addr < ORIGIN) {
-          /* Need to patch reset vector there */
+          /* Patch vectors by vector_table??? */
           handler *new_vector = (handler *) addr;
           flash_write((uintptr_t) &new_vector[1], (const uint8_t *)
                       &vector[1], sizeof(handler));


After writing Gnuk for DFU to the board, at the first run, it writes new
SYS killing DFU, and in the code above, the reset vector is patched.

This is no problem, if a user upgrades Gnuk with reGNUal at the first
run (because, for the first run, SCR->VCR and MSP are configured by DFU,
and then configured again by old SYS).

For the second run, for me, it is more clear and clean if all vectors
are updated by vector_table of chopstx/entry.c.

Currently, it updates only the reset vector by old SYS reset routine
("old" means SYS for DFU, here).  For the second run (if any), the
control goes from new SYS:reset to old SYS:reset which again sets
SCR->VCR and MSP.  (In this transition, MSP is once set to 0xffffffff,
which is not correct.)

This sounds not great.  Well, it's acceptable, because nobody should
keep using Gnuk for DFU.


In this morning, I tried to modify the code, but I realized that the
sizeof(vector_table) is not determined at the compile time of main.c, in
the current code of chopstx/entry.c.  So, I didn't change the code.


Please make sure the second reset works well.  I mean, after writing
Gnuk for DFU (by DFU), reset (which kills DFU by new SYS), reset again,
and upgrade by reGNUal.
-- 



More information about the Gnuk-users mailing list