Firmware nachladen auf AT91SAM (über USB)

[Emanuel E. (eeick)]

Hallo,

zurzeit arbeite ich an einem Firmware Upload Mechanismus, welcher für 
folgenden Use-Case verwendet werden soll:
Der Nutzer steckt das USB-Gerät ein. Dieses wird in einem „dummen“-Modus 
gestartet und von Windows erkannt. Der Windows-Treiber lädt dann via USB 
die relevanten Programmteile nach. Nach Abschluss des FW-Uploads macht 
die HW einen Software-Reset und steht danach als voll-funktionsfähiges 
Gerät zur Verfügung. Die USB Endpunkte werden in diesem Schritt auch 
angepasst (um zusätzliche Funktionen erweitert).

Das USB-Gerät wird aktuell auf einem AT91SAM9260-EK realisiert. Soll 
aber später (wegen USB-HighSpeed) auf den AT91SAM9R64 portiert werden.

Mein erster Ansatz war es den SAM-BA Bootloader zu nutzen. Leider habe 
ich keinen Weg gefunden diesem meine USB-VendorID und ProductID 
unterzujubeln. Liege ich richtig mit der Annahme, dass Atmel dies 
bewusst verhindert um die Leute an ihre Hardware zu binden? Ich frage 
bewusst, da zum Beispiel der Cypress EZ-USB Chip einen ähnlichen 
Bootmechanismus hat, dieser aber die Vendor- und ProductID aus einem 
externen EEPROM nehmen kann.

Da dieser Weg also, meinem Kenntnisstand nach, nicht funktioniert habe 
ich an eine die folgende Lösung gedacht:
Ich umgehe das SAM-BA Bootrom komplett (Schade drum) indem ich BMS=0 
setze. Damit boote ich von externem Flash. In diesem lege ich meinen 
eigenen first-level Bootloader ab der sich um die folgenden Aufgaben 
kümmert:
 * Initialisierung und starten des PMC und PLL
 * Initialisierung einer einfachen USB-StateMachine, welche sich um 
Enumeration und FW-Upload kümmert.
 * Starten des second-level Bootloaders.

Nach einstecken des USB-Geräts wird zuerst einmal die Hardware 
initialisiert. Hierbei wird auch mein first-level bootloader aus dem 
Flash ins interne RAM kopiert und zur Ausführung gebracht. Die FW 
initialisiert den USB-Stack und startet die USB-Enumeration. Mein 
Windows-Treiber erkennt das USB-Gerät und startet einen FW Upload. Mein 
Bootloader nimmt die FW entgegen checkt diese und schreibt sie ins 
interne RAM. Der Code-Bereich der neuen Firmware darf sich nicht mit der 
des first-level Bootloaders überschneiden. Nachdem die neue FW kopiert 
wurde, ruft der first-level bootloader die neue main() auf.

Zu diesem Ablauf hätte ich noch ein paar Fragen:
 1. Den Datenblättern der AT91SAM9263 bzw. AT91SAM9R64 Architektur kann 
ich beim "Boot Program Algorithm Flow Diagram" lesen, dass nach der 
low-level Initialisierung der Hardware zuerst auf der SD-Card nach Code 
geschaut wird, dann im NandFlash und danach erst im DataFlash. Kann man 
diese Bootschritte irgendwie überspringen und direkt zum SPI 
DataFlash-Boot springen? Im Diagramm wird von einem Timeout pro stage 
von bis zu 1s gesprochen. Das scheint mir doch reichlich lang.

 2. Wie lange wird es wohl dauern, bis mein first-level Bootloader 
bereit ist die USB-Enumeration durchzuführen. Gibt es dazu 
Erfahrungswerte?

 3. Wie wird der Sprung vom first-level bootloader auf die neue Firmware 
am besten realisiert? Mit einem LongJMP auf die Adresse von main() oder 
durch ein überschreiben des ARM Vectors auf der Adresse 0x0 und danach 
ein JMP auf 0x0. Oder existiert eine bessere Vorgehensweise?

Vielen Dank für eure Hilfe im Voraus. Ich freue mich auch über 
alternative Vorschläge.

Viele Grüße

Emanuel

[gerhard (Gast)]

hallo,
hier ein paar anmerkungen zu deinem thread:

>Soll aber später (wegen USB-HighSpeed) auf den AT91SAM9R64 portiert >werden.
da solltest du aber einiges an zeit und geduld mitbringen da diese type 
zwar inoffiziel schon angekündigt ist, aber wer atmel kennt setzt solche 
dinge erst ein wenn diese den status "production" hat.

>Der Nutzer steckt das USB-Gerät ein. Dieses wird in einem „dummen“-Modus
>gestartet und von Windows erkannt. Der Windows-Treiber lädt dann via USB
>die relevanten Programmteile nach.
ein usb treiber der firmware nachladen kann ist mir noch nicht 
untergekommen. normalerweise erfolgt ein fw-update durch eine windows 
applikation. da die AT91SAM9 auch über eine usb host funktionalitöt 
verfügen würde cih das fw-update über einen usb-stick durchühren.


>Mein erster Ansatz war es den SAM-BA Bootloader zu nutzen. Leider habe
>ich keinen Weg gefunden diesem meine USB-VendorID und ProductID
>unterzujubeln. Liege ich richtig mit der Annahme, dass Atmel dies
>bewusst verhindert um die Leute an ihre Hardware zu binden?
sam-ba ist ein recovery tool, soll heißen wird nur eingesetzt wenn sonst 
nichts mehr geht.
das die id's fixiert sind liegt daran, dass sam-ba im rom liegt und 
daher die id nicht geändert werden kann. ist aber auch aus meiner sicht 
nicht notwendig. atmel stellt eine entsprechende dll zur verfügung über 
die eine pc-appliaktion zugrff auf sam-ba hat.

gruss
gerhard