Re: [Fud] Constrained Firmware update challenge

Michael Richardson <> Mon, 17 April 2017 15:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 364CA131443 for <>; Mon, 17 Apr 2017 08:26:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dSKDg7xvysDe for <>; Mon, 17 Apr 2017 08:26:22 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 93BA2130140 for <>; Mon, 17 Apr 2017 08:26:22 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id C77252009E; Mon, 17 Apr 2017 11:51:21 -0400 (EDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 3CE00636BB; Mon, 17 Apr 2017 11:26:21 -0400 (EDT)
From: Michael Richardson <>
To: Carsten Bormann <>
In-Reply-To: <>
References: <> <>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Mon, 17 Apr 2017 11:26:21 -0400
Message-ID: <>
Archived-At: <>
Subject: Re: [Fud] Constrained Firmware update challenge
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: FUD - Firmware Updating Description <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Apr 2017 15:26:24 -0000

Carsten Bormann <> wrote:
    > How do you update that bootloader (which now contains the majority of
    > the code on the device, by the way)?

I think that it may be possible to significantly simply that code path
such that it does not have so much code.  Updates may be impossible
(burnt into ROM), or it might just be a special part of the flash that
is seperate from the main code.

Things I would expect to leave out would include:
       - L2 neighbour cache and L3 routing
       - fragment creation (just re-assembly)
       - neighbor discovery
       - RPL
       - DTLS and/or OSCOAP setup.
       - authorization: public key handling, certs if used, ACE tokens, DH
       - interrupts (everything polled I/O)

This is part of my postulate, and perhaps you will reasonably disagree with
the assumption that this can be done.  I believe that the code would be
seperate from the normal code.   Done wrong it could contain the majority
of the code, but done well, I think it would be perhaps 20%.

Effectively, we no longer double buffer the entire system, just the totally
minimal code required to load new code.  It could alternatively be that the
bootloader code is used as a kind of "BIOS" via subroutines.

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-