Bootloader SD card encriptado, para ARM STM32

[planeta9999]

Ahora entiendo.. nunca tuviste que actualizar tu bootloader por alguna razon ?.

No, ya me he cuidado que de funcione bien haciendo muchas pruebas antes de darle el visto bueno, aunque en caso de emergencia, con el producto en la calle, si detectara un bug en el bootloader, siempre podría hacer la operación contraria, osea crear un firmware que regrabe el bootloader.

El caso es que cuando el bootloader pasa el control al firmware, las páginas que ocupa se podrían borrar y regrabar si fuera necesario, pero si esa tarea sale mal, la placa se quedará bloqueada irreversiblemente, también si durante ese proceso se cortara la corriente eléctrica, no habría manera de volver a cargar el bootloader y el cliente tendría que envíar la placa para reprogramarla.

Solo contemplo un caso en el que podría borrar el bootloader, es si detecto una placa pirateada, en ese caso desde el firmware podría destruir el bootloader para dejar la placa inservible.  

[juaperser1]

El CD, es realmente un DVD con casi 4Gb de información, tutoriales, esquemas, datasheet, y ejemplos.
He sacado los programas ejemplo para todos los F407, y los he colgado en Mega, en un RAR que ocupa 180 megas. Hay más ejemplos para otros STM32 F1, F2, F3.
El esquema está, pero no pone la referencia del joystick.

En un rato pongo los enlaces para la descarga de los ejemplos y el esquema.

Muchas gracias amigo estoy deseando tener mi hardware en las manos para probar todo lo que me estas enseñando jeje,

por cierto estas son algunas de las características que de momento tiene:

STM32f439
128 Mbits de memoria SDRAM externa
32 Mbits de nor Flash externa
ethernet 10/100 con PHY
x2 USB FS 2.0 OTG
x1 USB HS 2.0 OTH (480Mb/s) con PHY
x1 Bus can
pantalla 5,7" RGB interface 24Bits y panel tactil capacitivo
lector de tarjetas microSD (Esto lo puse porque me convenciste del bootloader por tarjeta)

y algunas cositas mas que todavia estoy diseñando un saludo

[planeta9999]

¿ Para que usas la flash externa ?.
Podrías usar la tarjeta SD como si fuera un disco FAT32, con una capacidad de almacenamiento muy superior.

[juaperser1]

la he puesto para probar el boot alternativo, simplemente por eso pero no por que me haga falta, de todas formas quizá la elimine del diseño final, pero me parecia interesante tenerla para probar el boot este que nunca he utilizado.

[planeta9999]

Otras rutinas que necesitaré, son las que comprueban si hay o no cargada una aplicación de usuario (firmware) para saltar a ella o no. Si no hay firmware cargado y no hemos puesto una tarjeta SD con el firmware, el bootloader se debe de quedar a la espera de la tarjeta SD o entrar en un bucle infinito while (1).


Definición de dirección inicial del firmware, en este caso la primera dirección del Sector 4 del STM32F407. Se reservarían los primeros 64K para el Bootloader (Sectores 0 a 3, de 16K cada uno).

Código: [Seleccionar]

#define USER_CODE_FLASH  ((u32)0x08010000)

Rutina que comprueba si hay firmware cargado. No entiendo todavia que está haciendo ese if ((sp & 0xFFFE7FFF) == 0x20000000). Entiendo que si no hay firmware, la dirección 0x08010000 estará a 0xFFFFFFFF.

Código: [Seleccionar]

bool checkUserCode (u32 usrAddr) {
  u32 sp = *(vu32*) usrAddr;

  if ((sp & 0xFFFE7FFF) == 0x20000000) {
    return (TRUE);
  } else {
    return (FALSE);
  }
}

Si hay firmware cargado, salta a aplicación de usuario.

Código: [Seleccionar]

if (checkUserCode(USER_CODE_FLASH)) {
    jumpToUser(USER_CODE_FLASH);

Rutina para saltar a aplicación de usuario (firmware). De ahí sobran algunas cosas, porque está sacada de un bootloader USB. No entiendo porque le suma 0x04 a la dirección a la que ha de saltar, tendré que hacer pruebas y leer más documentación, por lo que he visto tiene algo que ver con lo que llaman "Vector table", Reset Vector y las interrupciones.

Código: [Seleccionar]

void jumpToUser (u32 usrAddr) {
  typedef void (*funcPtr)(void);

  u32 jumpAddr = *(vu32*) (usrAddr + 0x04); /* reset ptr in vector table */
  funcPtr usrMain = (funcPtr) jumpAddr;

  /* tear down all the dfu related setup */
  // disable usb interrupts, clear them, turn off usb, set the disc pin
  // todo pick exactly what we want to do here, now its just a conservative

#ifdef STM32F2
  nvicDisableInterrupts();
#else
  flashLock();
  usbDsbISR();
  nvicDisableInterrupts();
  usbDsbBus();
#endif

  systemReset(); // resets clocks and periphs, not core regs


  __MSR_MSP(*(vu32*) usrAddr);              /* set the users stack ptr */

  setPin(LED_BANK,LED);
  usrMain();                                /* go! */
}

[planeta9999]

Gracias a la información de los foros de ST, voy entendiendo algunas cosas, y considerando otras que desconocía.
Resumiento, sobre mis últimas dudas:

La dirección de salto a la aplicación de usuario, debe de ser la Primera dirección de la aplicación + 4, ya que en la dirección inicial está la Tabla de Vectores, no el código ejecutable. Así que la llamada a la aplicación de usario podría quedar así, donde ApplicationAdress en mi caso estaría en 0x08010000:

Código: [Seleccionar]

pFunction Start = *(__IO uint32_t*) (ApplicationAddress + 4);
__set_MSP(*(__IO uint32_t*)ApplicationAddress);
Start();

En la aplicación de usuario (firmware), además de modificar el Linker Script para que la ROM ORIGIN apunte a la dirección 0x08010000, también hay que añadir esto dentro del main(), para reubicar la Tabla de Vectores (desconozco el porqué, pero hay que hacerlo).

Código: [Seleccionar]

NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x10000);  

Y cuando uno está de suerte, está de suerte, en los foros de ST, alguien publicó hace 3 años un bootloader para tarjetas SD con un STM32F103VC, no incluye encriptación, y requiere cambiar unas cuantas cosillas para adaptarlo a los STM32F4xx, pero el 80% del trabajo ya está hecho. El enlace de la descarga es este: http://www.mediafire.com/?2748w3w5kraifsv . Gracias Benjamin   .  Y si alguien lo quiere para los pequeñitos SMT32F1xx, pues ya lo tiene al 100%, solo falta añadirle las rutinas de desencriptación y arreando (XTEA, DES, AES...).

Y aquí algunos post interesantes de los foros de ST, sobre estas cuestiones:
Post 1
Post 2
Post 3

[KILLERJC]

La dirección de salto a la aplicación de usuario, debe de ser la Primera dirección de la aplicación + 4, ya que en la dirección inicial está la Tabla de Vectores, no el código ejecutable. Así que la llamada a la aplicación de usario podría quedar así, donde ApplicationAdress en mi caso estaría en 0x08010000:

En mi caso con el de TI el vector de reset se encuentra en una posicion + 4 tambien. Ya que la direccion (u offset) 0x0000.0000 se encuentra definido el top del stack, esto es lo que dice:

"Stack top is loaded from the first entry of the vector table on reset."

Luego como dije esta el vector de reset.

Y el tema del NVIC tmb.. para reubicar la tabla de vectores de excepciones e interrupciones.

Nuevamente gracias a vos cuando lei eso fui corriendo al datasheet y me ponia a pensar por que se ejecutaba el bootloader que posee la ROM cuando la direccion 0x0000.0004 estaba borrada 0xFF, por que no directamente lo hacia de la direccion 0x0000.0000 y ahora lo descubri

[andor]

Hola un saludo, hace tiempo que conocía el foro como visitante, pero hoy he decidido registrarme, para ver si aprendo algo de ARM y puedo colaborar en algún tema.
“Mis conocimientos son sobre todo de los PIC de 8 bit, en ASM.”

Me parece interesante este tema de bootloader por tarjeta SD, a ver si me puedo píllame alguna placa de desarrollo y realizo mis pruebas.
Veo que tiene cosas interesantes cono ID serie del dispositivo, por cierto como sea comentado puede ser muy útil.

Pero tengo algunas dudas:

Si protegido el bootloader, se puede hacer alguna lectura de su código (cargando alguna rutina que pueda leer esos datos y sacarlos hacia fuera)??
En esto micro STM32F4xxxx, puede ejecutar código desde la RAM  ¿?

Donde indicáis:
ROM  (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
La longitud 1024K hay que quitarle lo que ocupa el booloader (1024k – bootloader)
Perdon no lei lo que pulso el compañero, "Bueno, el tamaño de la flash disponible ya no serían 1024K, sino 1024K menos el tamaño del bootloader."

[planeta9999]

Si protegido el bootloader, se puede hacer alguna lectura de su código (cargando alguna rutina que pueda leer esos datos y sacarlos hacia fuera)??

No, por software no se puede extraer nada, todos aquellos inventos con programas "gusano" que permitían antaño volcar cosas en micros PIC, allá por el año 2000, no sirve con estos micros. Además como el firmware está encriptado, nadie puede cargar nada, a menos que conozca la clave de encriptación.

En esto micro STM32F4xxxx, puede ejecutar código desde la RAM  ¿?

Lo desconozco, algo he oido, pero no lo he probado. De todas formas con 1 y 2 Megas de flash, no creo que necesites hacer uso de la RAM para cargar un programa.

Donde indicáis:
ROM  (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
La longitud 1024K hay que quitarle lo que ocupa el booloader (1024k – bootloader)
Perdon no lei lo que pulso el compañero, "Bueno, el tamaño de la flash disponible ya no serían 1024K, sino 1024K menos el tamaño del bootloader."

Si, eso le indica al enlazador cuanta RAM y Flash tiene para ubicar variables y programa, y en que direccion empieza cada memoria. Si le pones datos incorrectos, aunque compile, cuando lo cargues al micro no funcionará.

[andor]

"Además como el firmware está encriptado, nadie puede cargar nada, a menos que conozca la clave de encriptación."

Tienes razón, pero mi idea es que un usuario pueda subir su aplicación al micro, entonces si en su aplicación indica que lea direcciones de memoria y que las saque hacia fuera. Se jode el invento.

Lo ideal es tener una zona de memoria que este protegida sobre lectura, no tengo ni idea si se puede hacer alguien se le ocurre algo  ¿??

Mi otra idea es que se pueda ejecutar código desde la tarjeta sd, posiblemente el código hay que pasarlo a la ram, Pero esta la duda si puede ejecutar código desde la ram.

[planeta9999]

"Además como el firmware está encriptado, nadie puede cargar nada, a menos que conozca la clave de encriptación."

Tienes razón, pero mi idea es que un usuario pueda subir su aplicación al micro, entonces si en su aplicación indica que lea direcciones de memoria y que las saque hacia fuera. Se jode el invento.

Es que la utilidad de un bootloader encriptado no es esa. El firmware está encriptado precisamente para que NADIE pueda subir lo que quiera, solo la empresa que fabrica el producto es la que facilita el firmware ya encriptado al cliente.
 

Lo ideal es tener una zona de memoria que este protegida sobre lectura, no tengo ni idea si se puede hacer alguien se le ocurre algo  ¿??

¿ pero que quieres proteger ?, si es al propio bootloader no tiene sentido, son programas sencillos al alcance de cualquiera. Nadie hackea un microcontrolador para sacar su bootloader, por la red tienes montones de código fuente para hacer tu propio booloader, sin coste alguno.

Mi otra idea es que se pueda ejecutar código desde la tarjeta sd, posiblemente el código hay que pasarlo a la ram, Pero esta la duda si puede
ejecutar código desde la ram.

¿ Código desde una tarjeta SD ?, ahí si que lo puede ver y copiar cualquiera, e igualmente pueden hacer lo que dices al principio.
No entiendo lo que quieres hacer.

[andor]

Por cierto para manejar ehrtenet tengo que añadir algun circuito mas, algo he leido por algun sitio pero no lo tengo claro.

[planeta9999]

Para Ethernet necesitarás el transceptor para la capa física o un controlador Ethernet por SPI si el micro no tiene Ethernet integrado. Para el primero puedes usar el DP83848, y para el segundo el ENC28J60.

[andor]

Podeis echar un vistazo aki, http://openservodrive.com/resetting-stm32-option-bytes/  dice algo de desblokear la escritura.

[elotrogonzalo]

Muy interesante!, voy a leer el hilo y descargar los ejemplos, yo hace rato quiero implementar un programa con stm32f4 para el uso de tarjetas sd de más de 2gb FAT32

Con freescale implementé FAT16 con las notas de aplicación que ellos tienen en la pagina y anda muy bien.