Hi All,
We are also looking for the OTA function for the SAM R21 (ATMEL). What we
need would be:
- Use of an external SPI 256KB Flash ( Microchip SST25VF020B cost by 5K
is 0.42USD).
- The integrated startup code (bootloader) and update code are located in
a non-updateable memory location in the internal Flash protected by the
BOOTPROT bit active. (datasheet p 350)
- Secured update will use AES128 (coprocessor) and key exchange (hardware
RNG).
- The current firmware will write the new firmware into the external SPI
Flash memory. The integrity of every firmware segment is ensured by a 32 Bit
CRC Checksum. A function Verify packets will inform the number of pages
sent to the device (each function contain a 32 Bit CRC Checksum). When the
complete procedure is finished, (all pages of packets was verified) set a
flag in the EEPROM (emulation zone in internal Flash).
- Start the update code in internal Flash (protected bootloader area)and
erase the old firmware located in the internal Flash.
- Copy the new firmware in the Internal Flash from the SPI external
Flash, reset the update flag and restart the SAM R21.
- If the power is interrupted during the update process, the bootloader
must check if the update bit in emulated EEPROM is set, if yes, must to
restart the update process, if not start RIOT.
- Each firmware specify :
The Supplier ID (32 bit ID, for testing or without protection one
reserved supplier ID can be defined, the update will work if only this ID
has a valid checksum),
Product ID will be define by the developer and will offer to update
same products with this firmware,
Firmware version with major or minor version (only newer firmware
versions are accepted).
- Functions :
Each function include a Supplier ID, Product ID, Firmware version, Packet
CRC32 and
o Firmware version
o Supplier ID IPV6 ID global ???
o Product ID
o Target IP IPV6 address to which device the firmware is send.
Can be a multicast address.
o Interface which interface will be use
o OTA port UDP port
o Fragment size size of the packets should be send. Small value if
multicast is use.
o Packet Period value to define for not stopped an application
o Verify Packets number of pages sent, the receiver need to verify if
the checksums of the packets received are OK. If not the page number will be
resend. If all are OK, the sender will receive OK
o Execute Packets the server will send this command when it will have
the confirmation for all packets were received are OK to one or all devices
(multicast or unicast).
Next step will be to implement a dynamic loader (remove cost of the external
Flash), but it should be a long development and RIOT will have during this
time many improvements. (Here is maybe a good start:
<https://github.com/SGSSGene/RIOT/blob/pr_dynamic_loader/sys/elfloader/READM
E.md>
https://github.com/SGSSGene/RIOT/blob/pr_dynamic_loader/sys/elfloader/README
.md)
Waiting for your feedback !
----------------------------------------------------------------------------
--------------------------------------------------------------------------
De : devel [mailto:[email protected]] De la part de Joaquín Cabezas
Envoyé : mercredi 4 février 2015 08:35
À : [email protected]
Objet : Re: [riot-devel] Call for OTA (Over the Air Update) Task Force
Hi everybody,
we are also interested in this feature, and we are willing to collaborate to
achieve it. We have already looked at LWM2M and find it quite suitable for
our needs. Plus it's telco-friendly.
Best Regards,
Joaquín.
El 22/01/2015 a las 21:20, Joakim Gebart escribió:
On 01/20/2015 06:47 PM, Arvid Picciani wrote:
As discussed during Hack'n'Ack, lets organize a task force to address
a currently hot feature in RIOT: Over the Air Updates.
In Q1 2015 the company I work for is planning to contribute that
feature, so i would like to call everyone who is planning or
interested in the same feature to align goals.
- Who is interested in such feature, and what is your approach to OTA?
We (Eistec) are interested in this feature as well.
- When can we meet virtually (or physically in case anyone is in Berlin)?
Initially I would prefer to have a virtual meeting, but I think it would
be beneficial to have a physical meeting once a task force/working group
has been formed.
While when and from which buffer is totally application specific,
there are some
common Ideas how to approach OTA in the core os itself that i have
collected from people so far:
- Simply over-writing RIOT in flash with a new copy, by keeping the
flasher code external.
- Insert SD cards with a new image and reboot
- Two copies of RIOT on the same flash, with a boot loader selecting
the active one
- Re-flashing only the application part of RIOT over the air while
keeping the OS part forever.
- Any relevant concepts missing here?
Another method related to the SD card solution if there is external
memory available would be to download the new firmware image to external
memory (NOR flash or similar) and then tell the device to reboot into a
flasher/bootloader which checks the external memory for a new image and
perform the device flashing before jumping into the main entry point.
This way the bootloader could be kept small and placed in a reserved
area of the internal flash, at least if partial erases of the internal
memory are supported by the hardware.
While I do have a favorite approach, the goal of a first virtual or
physical meeting would be to figure out a common ground here, so we
can focus on implementing one set of standard features into the base
OS. Independent from the actual OTA approach, these are the core
features that we appear to need from RIOT so far.
- The ability to flash memory regions from a buffer
- Simple hashing (crc?)
- Reducing rom size
- Optimizing stacks
- Converting some statically allocated stacks to dynamic
- Define a common OTA header with at least a magic and the checksum
Open discussion points are wether we need:
- Cryptographically signed OTA updates
- Dynamic loader to support updating only parts of the binary
- A common boot-loader that can chain-boot riot from different memory
regions
- Are HW watchdogs necessary to check if the new image boots properly?
Feedback on these lists as well as other input on the requirements for
OTA are appreciated at this point.
I will collect responses to this mail and summarize the discussion,
and/or organize a meetup.
Have you looked at the LWM2M initiative? They have a firmware update
service specified in their registry. I have not yet had time to look
closer at it, though.
See
<http://technical.openmobilealliance.org/Technical/technical-information/omn
a/lightweight-m2m-lwm2m-object-registry>
http://technical.openmobilealliance.org/Technical/technical-information/omna
/lightweight-m2m-lwm2m-object-registry
and
<http://technical.openmobilealliance.org/tech/profiles/LWM2M_Firmware_Update
-v1_0.xml>
http://technical.openmobilealliance.org/tech/profiles/LWM2M_Firmware_Update-
v1_0.xml
Best regards,
Joakim Gebart
Eistec AB
<http://www.eistec.se> www.eistec.se
_______________________________________________
devel mailing list
<mailto:[email protected]> [email protected]
<http://lists.riot-os.org/mailman/listinfo/devel>
http://lists.riot-os.org/mailman/listinfo/devel
--
<http://www.adevice.es/>
Joaquín Cabezas
Director Comercial (CCO)
Adevice Solutions SL
C/ Leonardo da Vinci, nº 18
Edificio Tecnoincubadora Marie Curie, 3ª planta
Parque Científico y Tecnológico Cartuja 93
41092 Sevilla
Tfno: +34 644 297 831
Tfno: +34 954 463 170
<http://www.adevice.es> www.adevice.es
AVISO SOBRE CONFIDENCIALIDAD: Este documento se dirige exclusivamente a su
destinatario. Puede contener información confidencial sometida a secreto
profesional y su divulgación está prohibida en virtud de la legislación
vigente, se informa que si no es usted el destinatario o la persona
autorizada por el mismo, que la información contenida en este mensaje es
reservada y su utilización o divulgación con cualquier fin está prohibida.
Si ha recibido este documento por error, le rogamos que nos lo comunique por
teléfono, o e-mail y proceda a su destrucción. En el envío de e-mail no se
puede garantizar la seguridad ya que esta información puede ser modificada,
interceptada, o incompleta. El remitente no acepta responsabilidad por los
errores u omisiones en el contenido o anexos de este e-mail.
_______________________________________________
devel mailing list
[email protected]
http://lists.riot-os.org/mailman/listinfo/devel
