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
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.