Re: Auto-update protocol -- a baby step forward!

Hi Mike,

Mike Kaufmann wrote:

D Yuniskis wrote:
I meant the binary parts always to have the size of a flash page.
And then transfer the pages with changes, no matter if there is only
one byte changed in a page or all. So there would be not that much
Ah, OK. Yes, that makes more sense -- since you can't write a
fraction of a page.

But, you're hoping you can get by with changing some small
percentage of the pages (?)

You're right, I'm hoping ;-)

Yes -- though *knowing* this, you can try to arrange things
so that those that aren't likely to change are grouped
together (not as likely to be adjacent to things that *do*
change often)

Sounds like you're having a file system in your flash and your modules
are individual files (my device only uses on chip memory).
No, no filesystem. Rather, treat *the* flash as a "block
special device" (e.g., disk) and manage blocks discretely.
Much like you manage pages -- except I manage things in terms
of "entry points".

Here the question is, can you move your modules from one block of
flash to an other and run (or load) it from there?


In this case take the above scheme, replace old and new binary version
by module versions, put together all module images and place a table of
contents at the beginning. Then the device could look for the right
module version. And in case the update is interrupted the device can
skip the already updated modules.
Yes. The difference is, I need to process a "module" at a time
so that I can keep the old module "running" while its new image
is being downloaded and then flashed. I also have to make sure
modules are updated in a specific (not known, a priori) order.

So, I am looking at having one "module" that governs the
update process *in* the device. By convention, update that
module *first*. Then, activate it and let it control
how the other modules are updated (i.e., it can then
be very flexible in determining what happens when)

Then, when updating the update module with the update module it
must not run out of RAM, overwriting the old update module with
the new one, because in case of a power down of the device during
that you can't update any more modules.

You don't "update" a module until you know you have it
*and* that it has been flashed correctly. I.e., if
power fails, the "volatile" state defaults to
"use the old one" (meaning you have to recheck the
"new" one, again).

There are *lots* of races/hazzards :-(

And I think, you'll also have some start up module, which can't
be updated (may bee an RTOS), since controllers need a certain
address to start.

Yes, the startup points to the "old" version. As above.

The real gotcha comes if power glitches just as you are
making that final flash that says "use the new stuff".

Ah, users. One can write "In order to make your device secure you
have to replace the default key!" in letters big enough so the
sentence will fill up an entire page - they won't read it.
But after some security issue they'll call the support: "Why
wasn't my device secure?"
Exactly. I think the solution is just to leave that *out*
and force it to be specified. E.g., for the open source
devices, I can just leave a syntax error in the sources:

char secret[] = put something here

so it won't build without them putting *something* there
(and, if they fail to pick a *good* something, <shrug>
"Hey, *you* picked that key so why are you complaining to

This is good for people using the source code, but not for those
using a binary. They will just end up with an other default key
(but fortunately for you complaining to the one who made that binary).

Yes. For these "throw away" projects, I don't care -- I won;t
release a binary so *someone* will have to build a binary
from the sources (isn't that the purpose of FOSS? :> ) and
*they* can deal with those headaches.

For the "projects to come", I will build custom images
(as the sources will *not* be available)

I was more thinking about something like the device to demand the
user to enter a new key after first power up. But in your case this
is not an option, since you want your device to start working without
any kind of initial setup.

Again, for the throwaway projects, I will build *my* images
with the keys that *I* want in them (and others will build
their own images). I just don't want to bother with the
countless newbie questions for which "RTFM" is the answer.

Anyway, the default key in the source isn't the issue. It's no key,
it is just something to make the device work without the user having
to do some setup first (although, IMO he should be forced to set a key).

The question is: is it possible read the key which replaced the default
key by
Step 1: trying to read it over any interface the device offers (easy to
cover in software, just don't implement a function for this)
Not a problem.

Step 2: disassembling the device and than using a JTAG interface or
unsoldering the flash chip to read its contents (not to hard
to cover if the µC has some internal flash / EEPROM which can
be protected so it can't be read out with a JTAG interface)
Don't worry about this in production devices. If someone
uses dynamite to blast into a bank vault, the bank can at
least argue that they took reasonable measures to protect
their customers' belongings. (OTOH, if they leave the door
to the vault wide open... or, write the combination on a
slip of paper taped to the front of the vault door...)

Well, it depends on the number of devices using the same key. With
individual keys for each device you're of course right. One key for
each customer is also ok. But very likely not if one key is used for
all devices (if their number is large enough to be of any interest).

- the server should also check a new image before enabling it for an
I have been trying to avoid having the server do *anything*.
I.e., push all of these actions into the "compiler + makefile"
so the image *is* legitimate before it gets to the server
(then, all you have to worry about is someone tampering with
the image -- which you will detect when you try to download it)
A way around this might be to upload the current image for instance
once a day (may be at random times) to the update server. This way
a corrupted image will be replaced after about a day. The compiling
machine should be able to do that. It could also download the image
from time to time to check it.
The "compiling machine" may not have access to that server.
E.g., Cisco can't upload updates for my routers to *my*
server (because they "can't get in")

Then my idea is out of the question. I just thought, if you can
upload a new image to the update server you have the necessary
access rights.
But if you just inform the customers about updates i.e. by a news
letter, then you have to keep in mind that they do not download
updates N+1 to N+4 but N+5, which might only work, if at least N+3
was installed. Of course this may be of no concern for your

In the "projects to come" market, a customer would not want to
miss an update. It's not like updates are just "adding fluff";
if there is an update released, it is to address a particular

For the throwaway projects, if folks want to cherry-pick
which updates they want to install, then they can deal with
going from N to N+3 however they see fit :> (I suspect
they will take the easy way out and simply install N+1,
then N+2, then N+3)