Softwareversion im Flash hinterlegen.

[Thorsten M. (mightyshite)]

Hallo zusammen,

Problem: Ich möchte in meiner Software innerhalb der ersten paar Bytes 
über einen 2-Byte-Code die Versionsnummer der Software hinterlegen. 
Also, zum Beispiel, Byte 10 und 11 (oder ähnlich) ergeben zusammen die 
Version. Der Hintergrund ist der, dass ich meinen Bootloader entscheiden 
lassen möchte, ob er die neue Software aufspielen darf oder nicht.

Umgebung: Ich programmiere in C (GNU C-Compiler) in Atmel Studio 7 auf 
einem Atmega1284p-au.

Für Eure Unterstützung bedanke ich mich schon einmal herzlich.

[Bauform B. (bauformb)]

Im Linker-Script kannst du für jede Quelldatei oder sogar für jede 
struct genau festlegen, auf welche Adresse die gelinkt werden soll. Für 
deine 2 Bytes scheint eine eigene struct etwas übertrieben, aber (nur?) 
so kannst du die genaue Reihenfolge der Bytes im Flash festlegen. 
Außerdem könnten es leicht mehr als 2 Bytes werden, z.B. eine Prüfsumme; 
Appetit kommt beim Essen ;)

Ein Bootloader auf dem gleichen Chip könnte noch den gleichen Header mit 
"typedef struct" benutzen. Wenn man die hex-Datei mit einem PC-Programm 
verarbeiten möchte, ist das nicht mehr so einfach, deshalb habe ich 
gerne wirklich fixe Adressen.

Thorsten M. schrieb:
> Der Hintergrund ist der, dass ich meinen Bootloader entscheiden
> lassen möchte, ob er die neue Software aufspielen darf oder nicht.

Dazu sollte er eigentlich etwas mehr wissen, als nur die 
Firmware-Version. Ich hatte mal versucht, möglichst viel zu 
berücksichtigen und das in eine "Hardware-Signatur" zu packen. 
Zusätzlich zur Firmware-Version würde ich sowas in den Bootloader und 
die Anwendung einbauen und dann vergleichen

typedef struct  hw_compat_struct {
   uint32_t  rev  :  5; // PCB-Revision, MBZ, außer im Bootloader (0, 'A'&31)
   uint32_t  dash :  7; // Sachnummer (-01)
   uint32_t  pcb  : 20; // Sachnummer (100001 bis 999999)
   uint32_t  part;      // Reference Designator; Bitmap
   uint64_t  vid;       // Bestückungs-Variante und -Revision und ECO; Bitmap
} hw_compat_struct;

Ein paar wirre Gedanken dazu findet man im Anhang...

[Nop (Gast)]

Thorsten M. schrieb:
> Problem: Ich möchte in meiner Software innerhalb der ersten paar Bytes
> über einen 2-Byte-Code die Versionsnummer der Software hinterlegen.

Sollte da nicht normalwerwise eine Interrupttabelle liegen? Eventuell 
direkt danach, denn deren Größe steht ja fest. Da könntest Du Dir ein 
geeignetes struct oder auch einen String definieren und über Dein 
Linkerscript in eine Section direkt nach der Interrupttabelle hinlegen.

> Der Hintergrund ist der, dass ich meinen Bootloader entscheiden
> lassen möchte, ob er die neue Software aufspielen darf oder nicht.

Aber bitte nicht so, daß kein Downgrade mehr geht. Es gibt kaum etwas 
Blöderes, als wenn eine neue Software wegen neuer Bugs nicht geht, aber 
die Firmware auch kein Downgrade auf die Vorversion zuläßt (hallo, 
Asus).

[Andreas B. (bitverdreher)]

Hier:
Beitrag "MMC/SD Bootloader füt ATMega16"
wurde so etwas schon gemacht.

Nop schrieb:
> Aber bitte nicht so, daß kein Downgrade mehr geht. Es gibt kaum etwas
> Blöderes, als wenn eine neue Software wegen neuer Bugs nicht geht, aber
> die Firmware auch kein Downgrade auf die Vorversion zuläßt (hallo,
> Asus).

Wenn man nur die Versionsnr. (wie im Link) kontrolliert, hindert einen 
niemand daran, dem Bootloader mit einer höheren Version wieder die alte 
SW unterzujubeln.
Wenn einem das nicht gefällt, flasht man den Bootloader eben neu.

[Purzel H. (hacky)]

Ein downgrade generell zu verhindern ist eine maximal dumme 
Entscheidung. Da gibt's den Fall eines Devices, welches nach vielen 
Jahren ausfaellt. Die Umgebung wurde darauf angepasst und kann nicht 
mehr veraendert werden. Daselbe Device ist nicht mehr erhaeltlich, 
sondern nur das Identische mit neuer Firmware. und etwas anderer 
Funktionalitaet. Mit downgrade Moeglichkeit wurde das Neue passen, sonst 
eben nicht. Nicht, dass der Kunde das koennen muss, sondern der 
Produktmanager.
Der Kunde bezahlt sicher einen geringen Aufpreis fuer eine alte Version, 
aber nicht, dass sich jemand Stunden lange damit rumschlagen muss. Und 
wenn der Kunde ein alte Version will, sollte man die liefern koennen und 
wollen.

[Thorsten M. (mightyshite)]

Vielen Dank schon einmal an Alle.

Ein Downgrade verhindern möchte ich nicht, aber man kann den Kunden ja 
warnen und fragen, ob er das wirklich machen möchte. Bauform hat ja auch 
noch mehrere andere gute Gedanken genannt, was mit dieser Technik 
möglich ist.

Was mir jetzt noch fehlt, ist die Beantwortung meiner Frage. Bauform 
schreibt, dass das mit einem Linkerscript möglich ist, aber ich weiß 
leider nicht wie? Die von allen vorgeschlagenen Links habe ich gelesen, 
aber keine Antwort gefunden.

[Oliver S. (oliverso)]

Thorsten M. schrieb:
> Was mir jetzt noch fehlt, ist die Beantwortung meiner Frage.

Andreas B. schrieb:
> Hier:
> Beitrag "MMC/SD Bootloader füt ATMega16"
> wurde so etwas schon gemacht.

Oliver

[Bauform B. (bauformb)]

Thorsten M. schrieb:
> Die von allen vorgeschlagenen Links habe ich gelesen,
> aber keine Antwort gefunden.

Meinten Sie: habe zu viele Antworten gefunden?
Und fast alle sind zu 99% richtig, auch wenn das linker script überall 
total unterschiedlich aussieht. Es muss nämlich nicht nur zum Linker 
passen, sondern zu Compiler, Startup, ggf. libc, Sprache und evt. sogar 
zur IDE.

Der Linker bestimmt nur die Syntax und bietet sehr viele Möglichkeiten, 
die man (für uC) meist nicht braucht. Es kann sein, dass in deinem 
vorhandenen Script die Hälfte überflüssig ist, aber was genau? Du musst 
also dein vorhandenes Script behutsam erweitern und kannst nichts aus 
dem Internet einfach 1:1 übernehmen.

Egal, hier ist eins von mir für ein Programm namens gps. Es ist etwas 
gekürzt und für einen STM32 (AVR kann ich nicht), aber im Prinzip 
funktioniert es so.

/* gps.ld  linker script */

MEMORY
{
/* STM32L412KBT (32 + 8K RAM, 128K Flash) */
   hw_flash     (rx)  : ORIGIN = 0x08000000, LENGTH = 128K
   hw_sram1     (rx)  : ORIGIN = 0x20000000, LENGTH = 32K
   hw_sram2     (rw)  : ORIGIN = 0x20008000, LENGTH = 8K

   flash_syslib (rx)  : ORIGIN = 0x08000000, LENGTH = 31K
   flash_gps    (rx)  : ORIGIN = 0x08008000, LENGTH = 15K
   flash_tzdata (rx)  : ORIGIN = 0x0801f000, LENGTH = 4K

   st_reserved  (r)   : ORIGIN = 0x20000000, LENGTH = 12544
   ram_syslib   (rw)  : ORIGIN = 0x20008800, LENGTH = 2K
   ram_gps      (rw)  : ORIGIN = 0x20009800, LENGTH = 1K
}

SECTIONS
{
  /DISCARD/ : {
     *($hardware_hdr)
  }

  $image_header : {
     *($image_hdr)
     *($vectortable)
  } > flash_gps

  .text : ALIGN(8) SUBALIGN(8) {
     FILL (0xff)
     *(.text)
     *(.text.*)
     *(.rodata)
     *(.rodata.*)
     *(.gcc*)
     . = ALIGN(4);
text_end = .;
  } > flash_gps

  $stack : {
stack = .;
    . += 512;
tos = .;
  } > ram_gps

  .data : ALIGN(4) SUBALIGN(4) {
data_start = .;
     *(.data)
     *(.data*)
data_end = .;
  } > ram_gps AT > flash_gps

  .bss : ALIGN(4) SUBALIGN(4) {
bss_start = .;
     *(COMMON)
     *(.bss)
     *(.bss*)
bss_end = .;
  } > ram_gps
}

Interessant sind eigentlich nur die Zeilen nach $image_header. Die 
section $image_hdr stammt aus dieser Quelle:

// image-hdr.c
  
#include <stddef.h>
#include "image-hdr.h"

extern crt1_type    crt1;
extern uint32_t     stack, tos;

const image_struct __attribute__ ((section ("$image_hdr")))
image_hdr = {
   .top_of_stack      = &tos,
   .crt1              = crt1,

   .info_version      = HDR_VERSION,
   .image_type        = IT_PROGRAM,
   .dev_id            = 0x464,
   .crc               = HDR_MAGIC,
   .version           = 2,
   .revision          = 11
};

// image-hdr.h
  
#pragma once
#include <stddef.h>
#include <stdint.h>

static const uint32_t  HDR_MAGIC = 0xDEC11780;

typedef enum header_version_enum {  // die Version der image_struct
   HDR_2014     = 'B',
   HDR_NICE_TRY = 'C',
   HDR_2020     = 'D',
   HDR_VERSION  = 'E'
} header_version_enum;

typedef enum __attribute__ ((packed)) image_type_enum {
   IT_UNDEFINED,
   IT_BOOTLOADER,
   IT_SYSLIB,
   IT_PROGRAM,
   IT_DATA
} image_type_enum;

typedef void (crt0_type)(void);    // startup routine, bootloader
typedef int  (crt1_type)(int);     // application

// 'info_version' sollte zwecks Kompatibilitaet nicht verschoben werden und
// die ersten 4 Worte erst recht nicht.
// Ein paar Felder werden nicht im Quelltext (image-hdr.c) initialisiert,
// sondern vom ELF zu S19 Konverter; die sind mit 'S' markiert.
// Der sollte meckern, falls sie schon initialisiert sind und muss dafür
// sorgen, dass Strings mit '\0' terminiert sind.

typedef struct image_struct {
   uint32_t        *top_of_stack;       // 00   initial SP - Offset
   union {
      crt0_type       *crt0;            // 04   initial PC(system)
      crt1_type       *crt1;            // 04   initial PC(program)
   };
   crt0_type       *nmi;                // 08
   crt0_type       *hard_fault;         // 0c
   char             info_version;       // 10   'E'
   image_type_enum  image_type;         // 11   bootloader, program, shm,...
   uint16_t         dev_id;             // 12   DBGMCU_IDCODE.DEV_ID
   uint32_t         crc;                // 14 S
   uint32_t         source_date_epoch;  // 18 S unix time
   uint16_t         version;            // 1c S
   uint16_t         revision;           // 1e S
   char             name[9 + 1];        // 20 S
} image_struct;

_Static_assert (sizeof(image_struct) == 42, " Bad struct size");

[Frank M. (ukw) (Moderator)]

Man kann bei avr-gcc auch eine Section mit

-Wl,--section-start=...

als Option mitgeben.

Ein Beispiel findet man zum Beispiel hier: 
https://www.mikrocontroller.net/articles/Konzept_f%C3%BCr_einen_ATtiny-Bootloader_in_C#Speicherlayout_des_Bootloaders

Ist zwar für ATTiny, aber sollte auch für ATmega gelten.

[Thorsten M. (mightyshite)]

Ich möchte mich bei Allen bedanken. Jetzt muss ich zunächst einmal die 
Informationen verarbeiten und versuchen, daraus etwas für meine Software 
zu stricken. Es gibt da noch viele andere Baustellen.

Fühlt Euch alle gedanklich von mir in einen Biergarten eingeladen, mehr 
geht im Moment leider nicht...