¿Cuáles son las técnicas para permitir actualizaciones de software seguras en sistemas integrados?

Question

La actualización del software para dispositivos integrados a menudo tiene la posibilidad de "bloquear" el dispositivo, p. si el poder fallara mientras está escribiendo software para FLASH. Dos preguntas:

1. ¿Cuáles son algunas de las mejores prácticas para implementar el mecanismo de actualización a fin de minimizar la probabilidad de que el dispositivo sea "bloqueado"?
2. ¿Cuáles son algunas de las mejores prácticas para hacer que el proceso de actualización sea a prueba de fallas, de modo que se puedan recuperar eventos como fallas de energía al instalar software en FLASH?

Answer 1

Todo depende de la importancia de la aplicación. Los dos enfoques básicos (copia de seguridad y cargador de arranque) también se combinan a veces.

Muchos sistemas tienen un gestor de arranque de solo lectura (como redboot) y luego dos bancos de memoria flash (en el mismo chip, con mayor frecuencia). El gestor de arranque tiene una bandera para elegir desde qué banco arrancar. La bandera cambiará en función de eventos como actualizaciones (fallidas o exitosas), y así sucesivamente.

Por lo tanto, al actualizar, la versión en ejecución copia la nueva carga en el banco de respaldo, comprueba la suma de verificación, alterna el indicador de inicio y luego reinicia el dispositivo. El dispositivo se reinicia en el banco nuevo, con la nueva carga. Después del reinicio, la nueva carga puede copiarse en el banco de respaldo.

A menudo también hay un temporizador de vigilancia con un restablecimiento de hardware. De esta forma, si el firmware se vuelve loco, falla al patear al perro guardián, el restablecimiento de hardware reiniciará el dispositivo y el gestor de arranque buscará una carga segura.

El proyecto Open Mesh es un buen ejemplo de este enfoque.

Answer 2

sumas de comprobación en el flash interna, con una copia de seguridad por defecto si el CRC/Suma de control no funciona. De esta forma, si el dispositivo obtiene una suma de comprobación incorrecta, entonces sabe que la actualización no está completa y puede reiniciarse a firmware predeterminado/anterior almacenado en otro dispositivo.

Esto requiere algo de preinicio (tal vez en el gestor de arranque) para verificar la suma de comprobación. Un bit estático de código.

editar: Comentarios adicionales en otro lugar. Si desea comprobar el firmware incorrecto, no solo el firmware dañado, su checsum/checkdata también puede encapsular información de versión (y una comprobación de ese encabezado). Creo que los enrutadores Linksys hacen esto, lo que puede hacer que sea problemático reflash con firmware personalizado.

Answer 3

las sumas de comprobación son buenas, pero solo le salvan de flashear en datos corruptos. ¿Qué sucede si muestra un archivo de imagen con una suma de comprobación válida pero para un modelo de producto diferente? un cargador de arranque predeterminado de solo lectura al que se puede acceder en caso de corrupción de emergencia es lo mejor que he visto.

Answer 4

Más específicamente ...

descargar la imagen de sustitución a un área de memoria sin sobrescribir CUALQUIER del espacio del programa actual. Espere hasta que se complete la descarga, ENTONCES calcule y compare CRC.

Si el espacio es realmente un problema, puede hacer la 'copia de seguridad predeterminada' como 'modo de recuperación', pero es mucho más astuto no hacer esto de forma destructiva.

Si eres -realmente- hábil ...puede hacer una sola actualización de escritura en FLASH para indicarle al dispositivo que arranque desde la nueva ubicación del código. Esto hará ping/pong entre dos secciones de código totalmente separadas. Se trata de la forma más segura que puede hacer esto:

• siempre tienen un gestor de arranque de recuperación no actualizable (Nano-loader) que puede ser una señal para cargar un nuevo código de alguna manera, si todo va mal.
• Dos espacios de programa separados
• Cada espacio de programa tiene un campo "CRC", un "número de grabación" (más alto que el otro número de página de códigos) y una palabra "inválida" (todos Fs - no requieren borrar para actualizar el marcador "no válido")
• Una vez que se completa una descarga, verifique el CRC. Si es bueno, grabe el marcador "no válido" en el espacio del programa de la versión anterior.
• El cargador Nano comprueba el marcador "no válido" para saber desde qué arranque. En el caso de que ambos sean válidos, haga una verificación CRC. Si todavía válida tanto, a continuación, tomar el mayor número de entrada quemadura

Ah, y cuando la gente dice ... suma de comprobación no 'se compruebe la suma' ... ¿Es un CRC correcto.

Answer 5

1. Mantenga un cargador de arranque de sólo lectura en la memoria no importa lo
2. En el gestor de arranque, permitir que un método a prueba de fallos (por ejemplo, mediante la celebración de botón X durante el reinicio) de la recarga nueva memoria de programa a partir de una fuente disponible de entrada (Tarjeta SD, RS232, lo que sea).

Answer 6

En algunos dispositivos de laboratorio (en lugar de consumidores), he visto los tableros construidos con circuitos de programador. En el peor de los casos, los usos pueden abrir la carcasa, conectarse al programador y volver a cargar el software predeterminado, o devolverlo para que usted haga lo mismo. 'Por supuesto, esto cuesta dinero real.

Algunos paneles personalizados utilizados en algunos de mis proyectos han tenido ROM reemplazables. Esto es más tonto, pero menos conveniente.

Answer 7

Para responder a ambas preguntas, y con independencia de los recursos de hardware en particular:

• para que, antes de ejecutar cualquier código de la aplicación (en el arranque, o después de una descarga se ha completado), el gestor de arranque hace una comprobación CRC en la aplicación. Si no es válido, el gestor de arranque no ejecuta el código.

• Si el gestor de arranque decide que no puede ejecutar el código de la aplicación, debe poder indicar esto al usuario y comenzar nuevamente la descarga.

Estos claramente ser más importante si el procesador tiene insuficiente del flash para almacenar una aplicación de copia de seguridad, o RAM suficiente para guardar la nueva hasta que esté terminado la descarga.

En estos casos, tiene sentido que el archivo que se está descargando tenga un pequeño encabezado que permita al gestor de arranque determinar si el archivo es apropiado para el sistema. Este encabezado también podría tener un CRC. Si el encabezado es válido para este sistema, y ​​el CRC es correcto, entonces el gestor de arranque puede borrar el flash (¡pero no en sí mismo!) Y continuar la descarga. De lo contrario, aborta sin tocar el código de la aplicación existente.

Answer 8

En mi experiencia, se reduce a lo que su costo es, si puede permitirse tener el doble de código/espacio de datos en el dispositivo que necesita y puede reiniciar, es simple, almacenar la nueva versión en todos sus extra espacio, haga una verificación de suma de comprobación adecuada en la nueva imagen y también recomiendo una verificación más profunda en la nueva imagen de firmware, ya que podría fallar si no lo hace, por ejemplo, algún tipo de clave cifrada que garantice el origen de la nueva imagen. También puede hacerlo con memorias externas, por ejemplo, en un proyecto que utiliza un PIC, tenía una EEPROM externa para la nueva imagen de firmware y una bandera que, si se configuraba en el arranque, cargaría una nueva imagen de la EEPROM.

si no tiene tanta suerte, es decir, no puede pagar ese espacio, entonces la vida se vuelve más interesante y es probable que no exista una forma garantizada de evitar por completo la posibilidad de falla durante una actualización. En todos los casos, el gestor de arranque debe estar en una memoria protegida y si puede permitirse el espacio, debe tener alguna forma básica de conectividad externa, he hecho sistemas con controladores USB muy simples en el gestor de arranque y sistemas con UDP REALMENTE simple solo pilas de red. O bien le permitirá al menos obtener una nueva imagen del dispositivo si falla durante una actualización. En estos casos, recomiendo encarecidamente colocar el gestor de arranque en un área de memoria de solo lectura, perderá la capacidad de actualizarlo, pero una actualización no segura también no lo dejará con un dispositivo completamente oculto. En tal caso, el gestor de arranque es lo suficientemente pequeño para que pueda estar seguro de su corrección.

la última posibilidad es un sistema que necesita actualizar una parte de su código mientras se ejecuta ... esto es realmente complicado y generalmente requiere un control complejo sobre la ubicación de las funciones en la memoria y una mayor planificación en el diseño de memoria para lograr . No es divertido, pero es factible.

Answer 9

Sé que se responde a esta Q, pero algunas personas necesitan más fiabilidad. Si su proyecto es realmente crítico para la misión, puede seguir esta ruta.

El plan básico es tener siempre un plan de respaldo que no puede fallar.

1. tienen PIC u otro microcontrolador que puede programar la memoria flash del procesador real. Lo haces usar una suma de comprobación en un bloque de datos, y la interfaz a través de serie, usb o incluso ethernet (no te rías, no es tan difícil) Este dispositivo NO PUEDE ser reprogramado en el campo (o tal vez incluso) para que siempre tener un plan de respaldo Los PIC pueden ejecutar servidores web a través de PPP/SLIP o ehternet, por lo que su interacción no es necesariamente incómoda. Google TCP-Lean. Trata de no reírse. (El sitio es adecuado para el trabajo). Coloque el puerto de programación en otro lugar. La seguridad no está asegurada.

2. El programa se ejecuta en la CPU principal y ejecuta un gestor de arranque propio. Tiene tres programas: un gestor de arranque, un programa de mantenimiento y el programa real.

Esto permite realizar actualizaciones al proceso de inicio de arranque, así como también al programa. Puede ejecutar un cargador de inicio de copia de seguridad en un flash extra, con un perro guardián para restablecerlo y usar la copia de seguridad si no inicia.

Tiene una aplicación integrada actualizable, un gestor de arranque actualizable y un modo de mantenimiento actualizable. Y un modo de copia de seguridad que no puede fallar.

Espero que nadie lo encuentre útil.