Fragen zu Makefile-Konzept und Bootloader

[Frank (Gast)]

Hallo liebes Forum,

arbeite mit arm-none-eabi-gcc und habe ein paar generelle Fragen. Ist 
zwar nicht direkt gcc-spezifisch, ich erhoffe mir hier aber die besten 
Antworten ;-)

1. Bootloader
Verwaltet Ihr einen evtl. vorhandenen Bootloader als Teil der Anwendung? 
Sprich: Bootloader im Unterverzeichnis und immer gleichzeitig mit der 
Anwendung in die Verionsverwaltung?
Der Bootloader sollte recht schnell stabil werden und dann nur noch im 
Notfall angefasst werden.
Vorteil aus meiner Sicht: Anwendung und BL sind immer konsistent in der 
Versionsverwaltung. Code-Teile könnten einfach wiederverwendet werden
Nachteil: Bei vielen Anwendungen auf gleicher Basis wird er immer 
mittgeschleppt.

Wie ist Eure Meinung?

2. Makefile
Derzeit erzeugt mein Make-File die Dateistruktur der Quelldateien in 
einem "obj"-Verzeichnis für den Build noch einmal. Aus src/main.c wird 
obj/src/main.o; aus src/lib/foo/bar.c wird obj/src/foo/bar.o usw.
Übernommen habe ich das aus einem Basis-Makefile aus dem Netz. 
Funktioniert gut und ist übersichtlich, weil nicht alle der >100 Objekte 
und deren Listings etc. flach in einem Verzeichnis liegen. Allerdings 
stört mich dieser Automatismus im Moment im Zusammenhang mit der 
Bootloader-Frage, weil der Zugriff auf Dateien außerhalb des 
bootloader-Unterverzeichnisses einen entsprechenden Pfad für die Objekte 
nach sich zieht, der dann auch außerhalb des "obj"-Verzeichnisses liegt. 
Grrr :(

Wieder: Best Practice schaut bei Euch wie aus?

Vielen Dank und viele Grüße

[Dr. Sommer (Gast)]

Frank schrieb:
> Bei vielen Anwendungen auf gleicher Basis wird er immer mittgeschleppt.
Daher gibt es zB in git "module" , mit denen man externe repositories 
mit einer ganz bestimmten Version einbinden kann.

Frank schrieb:
> Funktioniert gut und ist übersichtlich,
Ja wird gerne so gemacht weil man die generierten Dateien von den 
manuell erstellten getrennt hat und leicht löschen etc. kann. Üblicher 
wäre allerdings ein Name wie "build" statt "obj".

Frank schrieb:
> weil der Zugriff auf Dateien außerhalb des
> bootloader-Unterverzeichnisses einen entsprechenden Pfad für die Objekte
> nach sich zieht,
Na und? Zum compilieren muss man ja auch auf Dateien ausserhalb des obj 
Verzeichnisses (Source) zugreifen? Oder wie war das gemeint?

[Peter D. (peda)]

Frank schrieb:
> 1. Bootloader
> Verwaltet Ihr einen evtl. vorhandenen Bootloader als Teil der Anwendung?

Nein.
Der Bootloader ist eine komplett eigenständige Anwendung. Er wird einmal 
erstellt und dann für jede Anwendung benutzt.

Der Bootloader sollte möglichst alle Targets unterstützen, die man zu 
verwenden plant.

Der Bootloader wird auch immer einzeln geflasht und dann erst über ihn 
die Applikation. Nur damit stellt man sicher, daß er überhaupt 
funktioniert und ein weitere Update möglich ist. D.h. daß keine HW- oder 
SW-Fehler vorliegen.

Wir hatten schonmal den Fall, daß der Fertiger beides zusammen geflasht 
hat und dann ein Update nicht möglich war, weil eine Zinnbrücke auf dem 
Board war.

P.S.:
Ups, Du meinst wohl nen Bootloader für Speichermedien bei jedem Reset. 
Dann vergiß mein Gesülze. Das bezieht sich auf Bootloader für einen MC.

[Frank (Gast)]

Vielen Dank für die Antwort.

Dr. Sommer schrieb:
> Daher gibt es zB in git "module" , mit denen man externe repositories
> mit einer ganz bestimmten Version einbinden kann.

Ja, allerdings liest man über git-submodule so viele Schauergeschichten, 
dass ich davon erstmal Abstand nehmen wollte.
git-subtree scheint eine Alternative zu sein, aber ich wollte mir am 
Anfang nicht gleich alle Hürden dieser Welt antun.

> Ja wird gerne so gemacht weil man die generierten Dateien von den
> manuell erstellten getrennt hat und leicht löschen etc. kann. Üblicher
> wäre allerdings ein Name wie "build" statt "obj".

In "build" landen die Dateien, die dann weiterverwendet werden. .elf, 
.hex, .sym, .map, .a2l ...

> Na und? Zum compilieren muss man ja auch auf Dateien ausserhalb des obj
> Verzeichnisses (Source) zugreifen? Oder wie war das gemeint?

Die Regel im Makefile sagt: Nimm den Quellpfad, hänge ein "obj/" davor 
und das ist dann der Pfad zum Objekt. Bei einer Quelle "../foo/bar.c" 
ergibt das "obj/../foo/bar.c". "obj/.." hebt sich gegenseitig auf und 
bar.o landet nicht in "obj/foo/bar.o" sondern in "foo/bar.o". Das muss 
bei dieser Regel auch so sein, gefällt mir aber nicht, weil es die 
Objekte somit irgendwo verstreut. Wenn die Quelle noch weiter oberhalb 
des Projekts liegt, landet das Objekt "irgendwo" im Dateisystem. Also 
ist dieses Vorgehen für mich untauglich, falls ich weiter Quellen 
überhalb des Projekts verwenden will.

[Frank (Gast)]

Auch Dir herzlichen Dank.

Peter Dannegger schrieb:
> Nein.
Klare Ansage :)

> Der Bootloader sollte möglichst alle Targets unterstützen, die man zu
> verwenden plant.
Puh, das klingt nicht so einfach aber sicher sinnvoll. Mit "Target" 
meinst Du verschiedene Controller einer Familie oder geht das bei Dir 
auch hersteller- oder gar architekturübergreifend? Bei mir hängt's 
aktuell ziemlich an Flash-Sektoren etc. Die Adressen definiert das 
Linker-File. Im Fall meines Cortex-M hole ich mir Stackpointer und 
Reset-Handler aus der Vektortabelle der Anwendung. Wie sieht das bei Dir 
aus?

> Der Bootloader wird auch immer einzeln geflasht und dann erst über ihn
> die Applikation. Nur damit stellt man sicher, daß er überhaupt
> funktioniert und ein weitere Update möglich ist. D.h. daß keine HW- oder
> SW-Fehler vorliegen.
Schlagendes Argument. Find ich gut.

> P.S.:
> Ups, Du meinst wohl nen Bootloader für Speichermedien bei jedem Reset.
> Dann vergiß mein Gesülze. Das bezieht sich auf Bootloader für einen MC.
Nein und nein. Ich vergess es nicht :) Konkret ist es im Moment der 
STM32F4 und es soll ein XCP (on CAN, später evtl. Ethernet)-Bootloader 
werden. Oberste Prämisse ist wie so oft die Unzerstörbarkeit durch 
Anwenderfehler und Flashabbrüche.

Unterstützt oder brauchst Du ein Bootloader-Update durch den Bootloader?

[foo (Gast)]

Frank schrieb:
> Unterstützt oder brauchst Du ein Bootloader-Update durch den Bootloader?

Zumindest im automotiv Bereich ist ein Bootloader Update Standard.