AVR-Bootloader für CF?

[Sebastian Voitzsch]

Hallo,

hat schon jemand einen Bootloader für den AVR gesehen/geschrieben, der sich
die Firmware von einer CF lädt? Serielles findet man ja in allen AppNotes -
das nützt mir nur wenig.

Danke,
Sebastian

 

[Ulrich Prinz]

Sebastian Voitzsch wrote:

Hallo,

hat schon jemand einen Bootloader für den AVR gesehen/geschrieben, der sich
die Firmware von einer CF lädt? Serielles findet man ja in allen AppNotes -
das nützt mir nur wenig.

Danke,
Sebastian

Äh, wie jetzt?

Du hast eine CF-Card auf der die Firmware für den AVR steht. Dieser soll
sich dann diese Firmware von der Karte in sein internes FLASH ziehen und
damit starten?

Das grundsätzlich ist dabei einfach. Da vernünftige CF-Cards auch als
Memory-Mapped arbeiten, kann man sie wie externen an den AVR
angeschlossenen Speicher lesen. Aufwendiger ist es dagegen, wenn man die
CF auf dem PC beschreibt und daher mit einem Dateisystem formatieren
muss. Dieses Dateisystem muß der AVR in seinem Bootloader ersteinmal
interpretieren können. Wenn man FAT nimmt ( und das ist ausreichend für
so kleine Medien) dann hält sich der Aufwand in Grenzen. Das FAT-System
ist in zahlreichen Quellen im Inet dokumentiert.

Gruß

--
Ulrich Prinz
----------------------------------------------------
"But befor you connect, be advised:
you are plugging into the supply from hell."
Datasheet LTC1625, Automotive Considerations, Linear Tech.

 

[Sebastian Voitzsch]

Ulrich Prinz wrote:

Sebastian Voitzsch wrote:

Hallo,

hat schon jemand einen Bootloader für den AVR gesehen/geschrieben, der
sich die Firmware von einer CF lädt? Serielles findet man ja in allen
AppNotes - das nützt mir nur wenig.

Danke,
Sebastian

Äh, wie jetzt?

Du hast eine CF-Card auf der die Firmware für den AVR steht. Dieser soll
sich dann diese Firmware von der Karte in sein internes FLASH ziehen und
damit starten?

Das grundsätzlich ist dabei einfach. Da vernünftige CF-Cards auch als
Memory-Mapped arbeiten, kann man sie wie externen an den AVR
angeschlossenen Speicher lesen.

Na ja, sagen wir fast. Denn ich muß - anders als bei "echtem" RAM der CF
erst sagen, welchen Sektor ich gerne hätte. Aber Routinen für die
CF-Ansteuerung habe ich, da liegt nicht das Problem.

Aufwendiger ist es dagegen, wenn man die
CF auf dem PC beschreibt und daher mit einem Dateisystem formatieren
muss. Dieses Dateisystem muß der AVR in seinem Bootloader ersteinmal
interpretieren können. Wenn man FAT nimmt ( und das ist ausreichend für
so kleine Medien) dann hält sich der Aufwand in Grenzen. Das FAT-System
ist in zahlreichen Quellen im Inet dokumentiert.

Klar - grundsätzlich bin ich auch soweit; mein Player kann FAT-Dateien
lesen. Nur: das ganze ist in avr-gcc geschrieben und damit zu groß für
einen Bootloader (max. 1k, wenn ich das Datenblatt richtig verstanden
habe). Dazu müßte ich also auf Assembler umsteigen. Und bevor ich das
mache, wollte ich halt fragen, ob jemand sowas schon in der Schublade hat.

Gruß,
Sebastian

 

[Markus Zingg]

Das grundsätzlich ist dabei einfach. Da vernünftige CF-Cards auch als
Memory-Mapped arbeiten, kann man sie wie externen an den AVR
angeschlossenen Speicher lesen.

Falsch! Das ist ein weit verbreiteter Irrtum. Der ganze sog. Memory
Mapped Mode einer CF bezieht sich aleine auf die Register zur
programierung der Karte. Du musst in jedem Fall Code haben welcher
einen Sektor liest. Wahlfreier zugriff auf Sektordaten ist nicht im
Adressraum der CF zu haben. D.h. die Daten auf die zugegriffen werden
sollen müssen zuerst in's Ram - oder in anderen Worten die CF hat nur
ein 8 oder 16 bit breites Datenregister! Es gibt noch den Trick mit
der Adressleitung 10, aber dort geht es nur darum
Memoryblockverschiebeoperationen des Hostprozessors zu unterstützen
indem die CF bei gesetzter A10 Leitung alle anderen Adressleitungen
ignoriert und somit automatisch Adressse 0 addressiert (das
Datenregister)

HTH

Markus

 

[Helmut Neemann]

Sebastian Voitzsch schrieb:

Klar - grundsätzlich bin ich auch soweit; mein Player kann FAT-Dateien
lesen. Nur: das ganze ist in avr-gcc geschrieben und damit zu groß für
einen Bootloader (max. 1k, wenn ich das Datenblatt richtig verstanden
habe). Dazu müßte ich also auf Assembler umsteigen. Und bevor ich das
mache, wollte ich halt fragen, ob jemand sowas schon in der Schublade hat.

Wo ist denn Dein Problem? Oder bekommst Du auch einen kurzen Bootloader,

der nur nach einer bestimmten Datei auf der CF-Karte schaut, und diese,
wenn er sie findet, einließt und ins Flash schreibt nicht in 1k-Word hinein?

mfg
Helmut

 

[Sebastian Voitzsch]

Helmut Neemann wrote:

Sebastian Voitzsch schrieb:

Klar - grundsätzlich bin ich auch soweit; mein Player kann FAT-Dateien
lesen. Nur: das ganze ist in avr-gcc geschrieben und damit zu groß für
einen Bootloader (max. 1k, wenn ich das Datenblatt richtig verstanden
habe). Dazu müßte ich also auf Assembler umsteigen. Und bevor ich das
mache, wollte ich halt fragen, ob jemand sowas schon in der Schublade
hat.

Wo ist denn Dein Problem? Oder bekommst Du auch einen kurzen Bootloader,
der nur nach einer bestimmten Datei auf der CF-Karte schaut, und diese,
wenn er sie findet, einließt und ins Flash schreibt nicht in 1k-Word
hinein?

Mein Problem ist der Assembler. Die bisherigen Sachen habe ich in C gemacht,
das ist einiges "übersichtlicher". Zumal für die FAT-Geschichten einige
Berechnungen (Start der FAT, CHS-Umrechnung, Start des Datenbereichs)
notwendig sind.

Mein Erstversuch (der allerdings auch noch nicht funktioniert...) sieht
erstmal vor, daß die Firmware von Sektor 1 an fortlaufend auf der Karte
steht. Wenn das funktioniert, wird FAT dazugebastelt.

Sebastian

 

[Holger Klabunde]

Moin,

hat schon jemand einen Bootloader für den AVR gesehen/geschrieben, der
sich die Firmware von einer CF lädt? Serielles findet man ja in allen
AppNotes - das nützt mir nur wenig.

welchen AVR benutzt du eigentlich ?

Klar - grundsätzlich bin ich auch soweit; mein Player kann FAT-Dateien
lesen. Nur: das ganze ist in avr-gcc geschrieben und damit zu groß für
einen Bootloader (max. 1k, wenn ich das Datenblatt richtig verstanden
habe). Dazu müßte ich also auf Assembler umsteigen. Und bevor ich das
mache, wollte ich halt fragen, ob jemand sowas schon in der Schublade hat.

wie kommst du darauf das ein in Assembler geschriebener Bootloader kleiner
wird als das was avr-gcc erzeugt ? Da mußt du dich aber schon mächtig ins Zeug
legen um da noch mal ein paar Prozent Ersparnis rauszuholen.

Nimm doch einfach einen ATMega32. Da darf dein Bootloader 2kB groß werden.
Oder einen ATMega128. Da darf er sogar 4kB groß werden.

Wo ist dein Problem ? Keine 10 Euro für einen größeren Prozessor übrig ?
Geiz ist geil oder was

Gruß
Holger

--
Dipl. Ing. (FH) Holger Klabunde
http://home.t-online.de/home/holger.klabunde/homepage.htm

 

[Ulrich Prinz]

Sebastian Voitzsch wrote:

Ulrich Prinz wrote:


Sebastian Voitzsch wrote:


Hallo,

hat schon jemand einen Bootloader für den AVR gesehen/geschrieben, der
sich die Firmware von einer CF lädt? Serielles findet man ja in allen
AppNotes - das nützt mir nur wenig.

Danke,
Sebastian

Äh, wie jetzt?

Du hast eine CF-Card auf der die Firmware für den AVR steht. Dieser soll
sich dann diese Firmware von der Karte in sein internes FLASH ziehen und
damit starten?

Das grundsätzlich ist dabei einfach. Da vernünftige CF-Cards auch als
Memory-Mapped arbeiten, kann man sie wie externen an den AVR
angeschlossenen Speicher lesen.


Na ja, sagen wir fast. Denn ich muß - anders als bei "echtem" RAM der CF
erst sagen, welchen Sektor ich gerne hätte. Aber Routinen für die
CF-Ansteuerung habe ich, da liegt nicht das Problem.

Ok, das habe ich vorausgesetzt.

Klar - grundsätzlich bin ich auch soweit; mein Player kann FAT-Dateien
lesen. Nur: das ganze ist in avr-gcc geschrieben und damit zu groß für
einen Bootloader (max. 1k, wenn ich das Datenblatt richtig verstanden
habe). Dazu müßte ich also auf Assembler umsteigen. Und bevor ich das
mache, wollte ich halt fragen, ob jemand sowas schon in der Schublade hat.

Da geht es Dir also genau andersherum wie mir. Ich mache alles in

Assembler und alle wollen immer, dass ich auf C umsteige.....

Also wenn ich das Datenblatt richtig gelesen habe, dann steht es Dir
vollends frei, welchen Sektor du wann beschreibst. Du kannst also den
Seriellen Bootloader da lassen wo er ist und er startet einen
Bootloader, der da steht, wo Du ihn haben willst und der so groß ist,
wie Du ihn haben willst. Der Sucht dann auf der FAT-Part nach der Datei
und lädt diese in das jederzeit zur Laufzeit programmierbare Flash.

Wenn Du jetzt sagst, dass das aber viel Platz benötigt, dann sage ich
'nö'. Das FAT-System muss ja nicht immer mit aktualisiert werden. Wenn
es funktioniert, kann es in den FAT-Boot-Loader einfach mit aufgenommen
werden. Aus dem Player kommt es dann raus. Der Player kann ja weiterhin
per Call auf diesen teil des Bootloaders zugreifen, muss also nicht
doppelt vorhanden sein.

Schade dass der AVR keine Soft aus dem RAM starten kann. Sonst könnte
man den Loader einfach von der CF ins RAM laden, starten, der ersetzt
das FLASH und startet neu. Schade...

Gruß
--
Ulrich Prinz
----------------------------------------------------
"But befor you connect, be advised:
you are plugging into the supply from hell."
Datasheet LTC1625, Automotive Considerations, Linear Tech.

 

[Ulrich Prinz]

Markus Zingg wrote:

Das grundsätzlich ist dabei einfach. Da vernünftige CF-Cards auch als
Memory-Mapped arbeiten, kann man sie wie externen an den AVR
angeschlossenen Speicher lesen.


Falsch! Das ist ein weit verbreiteter Irrtum. Der ganze sog. Memory
Mapped Mode einer CF bezieht sich aleine auf die Register zur
programierung der Karte. Du musst in jedem Fall Code haben welcher
einen Sektor liest. Wahlfreier zugriff auf Sektordaten ist nicht im
Adressraum der CF zu haben. D.h. die Daten auf die zugegriffen werden
sollen müssen zuerst in's Ram - oder in anderen Worten die CF hat nur
ein 8 oder 16 bit breites Datenregister! Es gibt noch den Trick mit
der Adressleitung 10, aber dort geht es nur darum
Memoryblockverschiebeoperationen des Hostprozessors zu unterstützen
indem die CF bei gesetzter A10 Leitung alle anderen Adressleitungen
ignoriert und somit automatisch Adressse 0 addressiert (das
Datenregister)

HTH

Markus

Fast falsch: Vernünftige Karten können den Memory-Mapped Zugriff auch
für die Daten. Das geschieht über eine einfache Erkennung des
Weiterlesens über die Sektorgrenze hinaus und funktioniert für bis zu
4kB große Fenster. Ein Random-Lesen einzelner Bytes in wahlfreier
Reihenfolge über den ganzen Adressraum der Karte geht nicht.
Weiterer Nachteil, bei einzelnen Billigkarten wurde dieser Modus
entweder eingespart oder nicht fertig implementiert.

Du hast natürlich Recht, adressieren muss man den Startpunkt
zuersteinmal. (Das habe ich aber als Bekannt vorausgesetzt)

Letztendlich ist es aber egal, da die Datei auf einem FAT-System liegt
und daher die mit der Datei verlinkten Sektoren einzeln angesprungen
werden müssen. Spätestens nach dem dritten Überschreiben der
Firmwaredatei wird diese in einzelne Sektoren zerlegt über die Karte
verstreut landen, weil MS gelöschte Dateien nach Möglichkeit nicht
überschreibt, wenn noch jungfäulicher Platz zu haben ist.

Dazu kommt, dass das übertragen der Bytes in das Flash eh nacheinander
geschieht, da der AVR keinen DMA hat. Es ist also egal, ob ich eine
CF->FLASH Memcopy mache, oder per PIO Mode lese. In letzterem spare ich
mir dann auch die zusätzlichen Adress-Leitungen.

Gruß
--
Ulrich Prinz
----------------------------------------------------
"But befor you connect, be advised:
you are plugging into the supply from hell."
Datasheet LTC1625, Automotive Considerations, Linear Tech.

 

[Sebastian Voitzsch]

Holger Klabunde wrote:

Moin,

hat schon jemand einen Bootloader für den AVR gesehen/geschrieben, der
sich die Firmware von einer CF lädt? Serielles findet man ja in allen
AppNotes - das nützt mir nur wenig.

welchen AVR benutzt du eigentlich ?

Pardon me. Es ist ein ATmega 162L (16k Flash, 1k RAM).

Klar - grundsätzlich bin ich auch soweit; mein Player kann FAT-Dateien
lesen. Nur: das ganze ist in avr-gcc geschrieben und damit zu groß für
einen Bootloader (max. 1k, wenn ich das Datenblatt richtig verstanden
habe). Dazu müßte ich also auf Assembler umsteigen. Und bevor ich das
mache, wollte ich halt fragen, ob jemand sowas schon in der Schublade
hat.

wie kommst du darauf das ein in Assembler geschriebener Bootloader kleiner
wird als das was avr-gcc erzeugt ? Da mußt du dich aber schon mächtig ins
Zeug legen um da noch mal ein paar Prozent Ersparnis rauszuholen.

Wenn ich meine C-Routinen benutze, lande ich bei ca. 3kb. Wenn ich mir dann
aber ansehe, was da an Assembler rauskommt, kann man das schon um einiges
kürzen (z.B. Overhead bei Funktionsaufrufen, Schleifen etc.). Aber
vermutlich ist eine Mischung am schlauesten.

Btw: wie teile ich dem GCC mit, an welcher Adresse mein Programm losgehen
soll?

Nimm doch einfach einen ATMega32. Da darf dein Bootloader 2kB groß werden.
Oder einen ATMega128. Da darf er sogar 4kB groß werden.

Wo ist dein Problem ? Keine 10 Euro für einen größeren Prozessor übrig ?
Geiz ist geil oder was

Nee ;o) Der 162 ist schon in der Schaltung drin. Es war eher der Reiz, für's
Firmware-Update nicht mehr das Gehäuse öffnen und ein Kabel anschließen zu
müssen. Karte mit Firmware rein, einschalten, fertig. Mehr oder weniger
(lehrreiche) Spielerei.


Gruß
Sebastian

 

[Sebastian Voitzsch]

Ulrich Prinz wrote:

Sebastian Voitzsch wrote:

Ulrich Prinz wrote:


Sebastian Voitzsch wrote:


Hallo,

hat schon jemand einen Bootloader für den AVR gesehen/geschrieben, der
sich die Firmware von einer CF lädt? Serielles findet man ja in allen
AppNotes - das nützt mir nur wenig.

Danke,
Sebastian

Äh, wie jetzt?

Du hast eine CF-Card auf der die Firmware für den AVR steht. Dieser soll
sich dann diese Firmware von der Karte in sein internes FLASH ziehen und
damit starten?

Das grundsätzlich ist dabei einfach. Da vernünftige CF-Cards auch als
Memory-Mapped arbeiten, kann man sie wie externen an den AVR
angeschlossenen Speicher lesen.


Na ja, sagen wir fast. Denn ich muß - anders als bei "echtem" RAM der CF
erst sagen, welchen Sektor ich gerne hätte. Aber Routinen für die
CF-Ansteuerung habe ich, da liegt nicht das Problem.

Ok, das habe ich vorausgesetzt.

Klar - grundsätzlich bin ich auch soweit; mein Player kann FAT-Dateien
lesen. Nur: das ganze ist in avr-gcc geschrieben und damit zu groß für
einen Bootloader (max. 1k, wenn ich das Datenblatt richtig verstanden
habe). Dazu müßte ich also auf Assembler umsteigen. Und bevor ich das
mache, wollte ich halt fragen, ob jemand sowas schon in der Schublade
hat.

Da geht es Dir also genau andersherum wie mir. Ich mache alles in
Assembler und alle wollen immer, dass ich auf C umsteige.....

Also wenn ich das Datenblatt richtig gelesen habe, dann steht es Dir
vollends frei, welchen Sektor du wann beschreibst. Du kannst also den
Seriellen Bootloader da lassen wo er ist und er startet einen
Bootloader, der da steht, wo Du ihn haben willst und der so groß ist,
wie Du ihn haben willst. Der Sucht dann auf der FAT-Part nach der Datei
und lädt diese in das jederzeit zur Laufzeit programmierbare Flash.

Nicht ganz, denke ich:

"Note that the user software can never read any code that is located inside
the RWW section during a Boot Loader software operation. The syntax
Read-While-Write section refers to which section that is being programmed
(erased or written), not which section that actually is being read during a
Boot Loader software update.

RWW Read-While-Write Section If a Boot Loader software update is
programming a page inside the RWW section, it is possible to read code from
the Flash, but only code that is located in the NRWW section. During an
ongoing programming, the software must ensure that the RWW section never is
being read. If the user software is trying to read code that is located
inside the RWW section (i.e., by a call/jmp/lpm or an interrupt) during
programming, the software might end up in an unknown state."

Ersteres klingt gar danach, also könne man aus dem Bootloader gar keine
Funktionen im Application Flash ausführen (?!). Zweiters ist nicht so
tragisch - ich könnte ja erst einen Sektor ins RAM laden, das Flashen
passiert dann nur aus dem NRWW-Bereich.

Wenn Du jetzt sagst, dass das aber viel Platz benötigt, dann sage ich
'nö'. Das FAT-System muss ja nicht immer mit aktualisiert werden. Wenn
es funktioniert, kann es in den FAT-Boot-Loader einfach mit aufgenommen
werden. Aus dem Player kommt es dann raus. Der Player kann ja weiterhin
per Call auf diesen teil des Bootloaders zugreifen, muss also nicht
doppelt vorhanden sein.

Diese Idee klingt doch mal richtig gut! Du hast nicht zufällig eine Idee
parat, wie ich Funktionen mit absoluten Adressen versehen kann?
Oder ich schreibe die Cluster, die der Bootloader belegt, in's EEPROM und
rufe dann erst den Bootloader auf - der dann ganz ohne FAT auskommt. Bei
einem 16k-File (abzüglich Bootloader etc.) kommen nicht viele Cluster
zusammen. Wenn ich die CF-Lese-Routinen dann noch nach Deiner obigen Idee
"share"....

Sebastian

 

[jetmarc]

wie kommst du darauf das ein in Assembler geschriebener Bootloader kleiner
wird als das was avr-gcc erzeugt ?

Vermutlich schon alleine deshalb weil man sich beim Schreiben eines
Bootloaders in Assembler auf andere Sachen konzentriert als bei einem
Treiber in C. Zum Beispiel achte ich in C auf Vollstaendigkeit,
beruecksichtige auch seltene Ausnahmefaelle, schreibe so dass der
gleiche Code auch auf dem PC laeuft (besonders wichtig zB wenn nicht
FAT verwendet wird und der PC spaeter die CF Medien beschreiben soll),
etc.

Dazu kommt dann noch das API (evt mit mehreren Schichten) welches man
im Bootloader auch weglassen kann. Man geht vom universellen hin zum
speziellen.

Insofern wird der Assembler Bootloader also schon alleine durch
Weglassen all dieser Sachen eingedampft (nicht dass man das in C
nicht koennte, aber man tuts normalerweise einfach nicht).

Naja und hinterher fuegt sich noch der ewige Streitpunkt der ASM
vs C Fraktion an, naemlich ob jetzt der Compiler oder der Mensch
den kuerzeren Code erzeugt. In Anbetracht des geringen Umfangs
eines Bootloaders tendiere ich doch stark zum Menschen Aber
da will ich eigentlich keinen Flamethread anfangen - die groesste
Ersparnis liegt im oben erwaehnten, das letztere ist nur noch
"Finetuning".

Marc

 

[jetmarc]

Du hast natürlich Recht, adressieren muss man den Startpunkt
zuersteinmal. (Das habe ich aber als Bekannt vorausgesetzt)

Ich kenn den von Dir erwaehnten Modus nicht, aber falls es sich
um ein "optionales" CF-Feature handelt, musst Du zudem zunaechst
abfragen ob das vorliegende CF es unterstuetzt (und eine Fallback
Funktion parat haben die ohne das Feature auskommt). Insofern
also eher kontra-produktiv fuer einen minimalistischen Bootloader.

Marc

 

[Ulrich Prinz]

Sebastian Voitzsch wrote:

Ulrich Prinz wrote:


Sebastian Voitzsch wrote:


Ulrich Prinz wrote:



Sebastian Voitzsch wrote:



Hallo,

hat schon jemand einen Bootloader für den AVR gesehen/geschrieben, der
sich die Firmware von einer CF lädt? Serielles findet man ja in allen
AppNotes - das nützt mir nur wenig.

Danke,
Sebastian

Äh, wie jetzt?

Du hast eine CF-Card auf der die Firmware für den AVR steht. Dieser soll
sich dann diese Firmware von der Karte in sein internes FLASH ziehen und
damit starten?

Das grundsätzlich ist dabei einfach. Da vernünftige CF-Cards auch als
Memory-Mapped arbeiten, kann man sie wie externen an den AVR
angeschlossenen Speicher lesen.


Na ja, sagen wir fast. Denn ich muß - anders als bei "echtem" RAM der CF
erst sagen, welchen Sektor ich gerne hätte. Aber Routinen für die
CF-Ansteuerung habe ich, da liegt nicht das Problem.

Ok, das habe ich vorausgesetzt.

Klar - grundsätzlich bin ich auch soweit; mein Player kann FAT-Dateien
lesen. Nur: das ganze ist in avr-gcc geschrieben und damit zu groß für
einen Bootloader (max. 1k, wenn ich das Datenblatt richtig verstanden
habe). Dazu müßte ich also auf Assembler umsteigen. Und bevor ich das
mache, wollte ich halt fragen, ob jemand sowas schon in der Schublade
hat.


Da geht es Dir also genau andersherum wie mir. Ich mache alles in
Assembler und alle wollen immer, dass ich auf C umsteige.....

Also wenn ich das Datenblatt richtig gelesen habe, dann steht es Dir
vollends frei, welchen Sektor du wann beschreibst. Du kannst also den
Seriellen Bootloader da lassen wo er ist und er startet einen
Bootloader, der da steht, wo Du ihn haben willst und der so groß ist,
wie Du ihn haben willst. Der Sucht dann auf der FAT-Part nach der Datei
und lädt diese in das jederzeit zur Laufzeit programmierbare Flash.


Nicht ganz, denke ich:

"Note that the user software can never read any code that is located inside
the RWW section during a Boot Loader software operation. The syntax
Read-While-Write section refers to which section that is being programmed
(erased or written), not which section that actually is being read during a
Boot Loader software update.

RWW Read-While-Write Section If a Boot Loader software update is
programming a page inside the RWW section, it is possible to read code from
the Flash, but only code that is located in the NRWW section. During an
ongoing programming, the software must ensure that the RWW section never is
being read. If the user software is trying to read code that is located
inside the RWW section (i.e., by a call/jmp/lpm or an interrupt) during
programming, the software might end up in an unknown state."

Also ich habe mich jetzt nicht durchs Datenblatt gewuselt, aber zum

einen ist es logisch, dass man sich nicht die Page untern Hintern
wegziehen kann, auf der die Software gerade läuft. Schau mal genauer
nach, ob das für den ganzen NRWW Bereich gilt, oder nur jeweils für
einen Sektor. Sprich, kann man nicht Software in einem NRWW Sektor
ausführen, wenn diese einen anderen NRWW Sektor schreibt?

Ersteres klingt gar danach, also könne man aus dem Bootloader gar keine
Funktionen im Application Flash ausführen (?!). Zweiters ist nicht so
tragisch - ich könnte ja erst einen Sektor ins RAM laden, das Flashen
passiert dann nur aus dem NRWW-Bereich.

Das ist ok, aber eigentlich ist das alles nicht nötig. Lade den Sektor

mit der Soft im NRWW Bereich in das RAM, dann speicherst Du den Sektor
durch einen Funktionsaufruf des Bootloaders. Wenn ich das richtig im
Kopf habe, dann kann der vorhandene Bootloader nämlich soetwas schon von
ganz alleine per Call xyz. Damit kannst Du den ganzen NRWW Teil updaten,
notfalls sogar deine eigene FAT-Routine überschreiben.

Wenn Du jetzt sagst, dass das aber viel Platz benötigt, dann sage ich
'nö'. Das FAT-System muss ja nicht immer mit aktualisiert werden. Wenn
es funktioniert, kann es in den FAT-Boot-Loader einfach mit aufgenommen
werden. Aus dem Player kommt es dann raus. Der Player kann ja weiterhin
per Call auf diesen teil des Bootloaders zugreifen, muss also nicht
doppelt vorhanden sein.


Diese Idee klingt doch mal richtig gut! Du hast nicht zufällig eine Idee
parat, wie ich Funktionen mit absoluten Adressen versehen kann?

Ich programmieren ausschließlich in Assembler, daher kann ich dazu nur
wenig sagen. In ASM ist das überhaupt kein Umstand absolut oder relativ
zu programmieren. In C habe ich dazu keinen Rat. Aber ich muss bald
damit anfangen, daher schau ich auch mal nach. Wenn Du was findest, dann
schreib einfach mal.

Oder ich schreibe die Cluster, die der Bootloader belegt, in's EEPROM und
rufe dann erst den Bootloader auf - der dann ganz ohne FAT auskommt. Bei
einem 16k-File (abzüglich Bootloader etc.) kommen nicht viele Cluster
zusammen. Wenn ich die CF-Lese-Routinen dann noch nach Deiner obigen Idee
"share"....

Lass uns das mal kurz perfektionieren:

FAT-Routine in der normalen Software an einer bestimmten Position. Es
werden so viele Sektoren wie möglich in das RAM gepackt. Der Grund ist,
dass die ganze FAT-Routine in das RAM passen muss. Dann kannst Du den
Bootloader nämlich mit dem Flashen der RWW ( excl. BootLoader) und der
NRWW Area beauftragen. Als _letztes_ überschreibst Du den FAT-Kram, denn
mit dem überschreiben ist nicht länger sichergestellt, dass der Proz
hinterher an einer sinnvollen Ecke landet, ein Byte daneben und schon
gehts in die Hose. Der Bootloader muss dann lediglich das Ende der
Prozedur erkennen und einen Neustart durchziehen.

Damit kannst Du dann alles überschreiben bis auf den Bootloader. Wenn Du
allerdings eine perfekt funkionierende FAT-Routine hast, dann kannst Du
diese auch danach starten und diese liest dann eine andere Datei
(BOOT.BIN) und überschreibt ihrerseits den Bootloader mit der eigenen
Routine ( Weil im RWW).

Nur so als Idee.
--
Ulrich Prinz
----------------------------------------------------
"But befor you connect, be advised:
you are plugging into the supply from hell."
Datasheet LTC1625, Automotive Considerations, Linear Tech.

 

[Ulrich Prinz]

jetmarc wrote:

Du hast natürlich Recht, adressieren muss man den Startpunkt
zuersteinmal. (Das habe ich aber als Bekannt vorausgesetzt)


Ich kenn den von Dir erwaehnten Modus nicht, aber falls es sich
um ein "optionales" CF-Feature handelt, musst Du zudem zunaechst
abfragen ob das vorliegende CF es unterstuetzt (und eine Fallback
Funktion parat haben die ohne das Feature auskommt). Insofern
also eher kontra-produktiv fuer einen minimalistischen Bootloader.

Marc
Jein, immerhin könnte man den Bootsector der CF Card schon ausnutzen und

immerhin 512Bytes auf einen Schlag im Memory Mapped lesen. Aber das geht
natürlich nicht, wenn die Karte statt Memory Mapped nur Autoincrement
macht und statt ein Fenster nur jeweils das nächste Byte / Word
präsentiert. Aber das Thema hat sich ja eh erledigt, die Idee die
FAT-Routinen an den Bootloader zu koppeln anstatt sie in der Soft selbst
zu behalten ist sehr viel flexibler.

Gruß,

--
Ulrich Prinz
----------------------------------------------------
"But befor you connect, be advised:
you are plugging into the supply from hell."
Datasheet LTC1625, Automotive Considerations, Linear Tech.

 

[Ulrich Prinz]

Sebastian Voitzsch wrote:

Helmut Neemann wrote:


Sebastian Voitzsch schrieb:

[...]
Mein Erstversuch (der allerdings auch noch nicht funktioniert...) sieht
erstmal vor, daß die Firmware von Sektor 1 an fortlaufend auf der Karte
steht. Wenn das funktioniert, wird FAT dazugebastelt.

Sebastian
Ich weiß nicht, ob es einfacher ist dem AVR gleich das FAT-ten

beizubringen, oder ersteinmal eine Software für den PC zu schreiben, die
die CF sektorweise beschreibt....

Gruß

--
Ulrich Prinz
----------------------------------------------------
"But befor you connect, be advised:
you are plugging into the supply from hell."
Datasheet LTC1625, Automotive Considerations, Linear Tech.

 

[Ulrich Prinz]

jetmarc wrote:

wie kommst du darauf das ein in Assembler geschriebener Bootloader kleiner
wird als das was avr-gcc erzeugt ?


Vermutlich schon alleine deshalb weil man sich beim Schreiben eines
Bootloaders in Assembler auf andere Sachen konzentriert als bei einem
Treiber in C. Zum Beispiel achte ich in C auf Vollstaendigkeit,
beruecksichtige auch seltene Ausnahmefaelle, schreibe so dass der
gleiche Code auch auf dem PC laeuft (besonders wichtig zB wenn nicht
FAT verwendet wird und der PC spaeter die CF Medien beschreiben soll),
etc.

Dazu kommt dann noch das API (evt mit mehreren Schichten) welches man
im Bootloader auch weglassen kann. Man geht vom universellen hin zum
speziellen.

Insofern wird der Assembler Bootloader also schon alleine durch
Weglassen all dieser Sachen eingedampft (nicht dass man das in C
nicht koennte, aber man tuts normalerweise einfach nicht).

Naja und hinterher fuegt sich noch der ewige Streitpunkt der ASM
vs C Fraktion an, naemlich ob jetzt der Compiler oder der Mensch
den kuerzeren Code erzeugt. In Anbetracht des geringen Umfangs
eines Bootloaders tendiere ich doch stark zum Menschen Aber
da will ich eigentlich keinen Flamethread anfangen - die groesste
Ersparnis liegt im oben erwaehnten, das letztere ist nur noch
"Finetuning".

Marc

Ich habe eigendlich kein Verständnis dafür, dass C und ASM Kollegen sich
um die Effizienz des Codes streiten. Es sind zwei verschiedene paar
Schuhe, die man je nach Aufgabengebiet einsetzt. Meine bisherigen
Controllereinsätze waren in zeitkritischen und auf Geschwindigkeit
optimierten Abläufen. Letztendlich hat auch nur das Ergebnis
interessiert. Da ist, wenn man auf preiswerte kleine Controller
angewiesen ist, nun mal Assembler von Vorteil und C lernen dauert zu lange.

Wenn man gröbere Abläufe oder auch so komplexe Sachen wie FAT-Zugriff
und aufwendige Menüstrukturen für das Human-Interface schreiben muss,
dann ist das in C allemal schneller. Das gebe ich gerne zu.

Inzwischen sind auch die kleinsten Controller für die aktuellen Projekte
viel zu schnell und ich habe mich dazu entschlossen den Mischweg zu
gehen. Der Vorteil einer Hochsprache ist nun mal auch die darin sehr
viel leichter erreichbare Readability durch Kunden und Kollegen.
Alles Zeitkritische wird per Inline-Assembler erledigt und ist damit so
präzise steuerbar wie zuvor.

Ich denke eine optimale Lösung kommt immer dann heraus, wenn
Hochsprachenverfechter und HardcoreAssembler sich zusammensetzten und
ein Projekt in vernünftige Häppchen für jeden teilen. Da ich momentan
noch keine Kollegen dieser Art habe, lerne ich nun C für uCs.

Toi, toi, toi und Gruß,

--
Ulrich Prinz
----------------------------------------------------
"But befor you connect, be advised:
you are plugging into the supply from hell."
Datasheet LTC1625, Automotive Considerations, Linear Tech.

 

[Sebastian Voitzsch]

Ulrich Prinz wrote:

Ich weiß nicht, ob es einfacher ist dem AVR gleich das FAT-ten
beizubringen, oder ersteinmal eine Software für den PC zu schreiben, die
die CF sektorweise beschreibt....

Software schreiben? Ist nicht nötig: dd if=rom.bin of=/dev/hda bs=512 ;o)

Sebastian

 

[Sebastian Voitzsch]

Ulrich Prinz wrote:

Also ich habe mich jetzt nicht durchs Datenblatt gewuselt, aber zum
einen ist es logisch, dass man sich nicht die Page untern Hintern
wegziehen kann, auf der die Software gerade läuft. Schau mal genauer

Ist klar. Die Frage ist nur, wie man das "can never read any code that is
locate inside the RWW section during a Boot Loader software operation"
verstehen soll. Während des page write (in diesem Bereich) geht's nicht -
aber das steht eben nicht da. Anderes habe ich nicht gefunden.

nach, ob das für den ganzen NRWW Bereich gilt, oder nur jeweils für
einen Sektor. Sprich, kann man nicht Software in einem NRWW Sektor
ausführen, wenn diese einen anderen NRWW Sektor schreibt?

Ich werde das wohl ausprobieren müssen.

Ersteres klingt gar danach, also könne man aus dem Bootloader gar keine
Funktionen im Application Flash ausführen (?!). Zweiters ist nicht so
tragisch - ich könnte ja erst einen Sektor ins RAM laden, das Flashen
passiert dann nur aus dem NRWW-Bereich.

Das ist ok, aber eigentlich ist das alles nicht nötig. Lade den Sektor
mit der Soft im NRWW Bereich in das RAM, dann speicherst Du den Sektor
durch einen Funktionsaufruf des Bootloaders. Wenn ich das richtig im
Kopf habe, dann kann der vorhandene Bootloader nämlich soetwas schon von
ganz alleine per Call xyz. Damit kannst Du den ganzen NRWW Teil updaten,
notfalls sogar deine eigene FAT-Routine überschreiben.

Höö? Vielleicht muß ich den Absatz morgen nochmal lesen...

...
Ich programmieren ausschließlich in Assembler, daher kann ich dazu nur
wenig sagen. In ASM ist das überhaupt kein Umstand absolut oder relativ
zu programmieren. In C habe ich dazu keinen Rat. Aber ich muss bald
damit anfangen, daher schau ich auch mal nach. Wenn Du was findest, dann
schreib einfach mal.

Mach' ich. Wir sollten uns einfach zusammen tun ;o)

<...>

Lass uns das mal kurz perfektionieren:

FAT-Routine in der normalen Software an einer bestimmten Position. Es
werden so viele Sektoren wie möglich in das RAM gepackt. Der Grund ist,

Bei 1024 Byte RAM passen max. 2 Sektoren rein - da komme ich nicht weit. Und
ständig wieder zurückspringen dürfte auch sehr unsicher sein - wehe, es hat
sich schon eine klitzekleine Funktion verschoben...

dass die ganze FAT-Routine in das RAM passen muss. Dann kannst Du den
Bootloader nämlich mit dem Flashen der RWW ( excl. BootLoader) und der
NRWW Area beauftragen. Als _letztes_ überschreibst Du den FAT-Kram, denn
mit dem überschreiben ist nicht länger sichergestellt, dass der Proz
hinterher an einer sinnvollen Ecke landet, ein Byte daneben und schon
gehts in die Hose. Der Bootloader muss dann lediglich das Ende der
Prozedur erkennen und einen Neustart durchziehen.

Ich favorisiere derzeit die "Cluster-Merk-Methode": Die normale Anwendung
sucht auf der CF nach einer Datei (firmware.bin). Wird diese gefunden,
werden die belegten Cluster (oder auch Sektoren, sind bei 16KB Flash ja
max. 32 Sektoren = 32 LBA-Adressen * 4 Bytes = 128 Bytes) in's RAM kopiert
und der Bootloader angesprungen. Dieser muß dann nur die readSector(ulong
lba)-Funktion enthalten, 32 Sektoren lesen und flashen - das kriege ich
locker in C im Bootloader unter. Über das Flashen der Bootloader-Sektion
mache ich mir dann später Gedanken, wenn das überhaupt noch nötig ist: ein
einfachs readSector() wird man wohl nicht so oft updaten müssen ;O)

Das Ganze hat nur einen Nachteil: ist die Firmware beschädigt, geht das
Update nicht mehr. Dafür könnte man aber natürlich dann mal ein Kabel
anschließen.

Sebastian

 

[Colin]

[snip]

Habt ihr schonmal an die LILO methode gedacht? LILO hat keine Ahnung
von FAT, ext2 o. ä. sondern merkt sich einfach den Sektor wo der
Kernel liegt und ließt den einfach raus, GRUB hingegen 'kennt' die
Pappenheimer.

Korrigiert mich wenn ich da was falsch verstanden hab .

Du könntest ja in die ersten 2 Byte der Datei die Länge hinterlegen
(ich weiß, Pfusch), dann kannst du dir deine FAT Behandlung sparen.
Wenn du mit Windows die Datei allerdings änderst (besser:
verschiebst/löschst) wird sie sehr wahrscheinlich fragmentiert oder
verschoben.

Mfg,

Colin