Systemarchitektur Pandora (BIOS / Firmware)

[xyta]

hallo,

mich würde mal genauer interessieren, wie die Pandora ihr Betriebssystem lädt. Der ARM-Core wird hochgefahren... Dann lädt er irgendwie das Angström. Das kann er anscheinend vom internen Speicher, von den beiden SD-Slots oder dem USB-Port aus tun.

Dafür muss er natürlich wissen, dass es diese Möglichkeiten gibt. Auf dem PC gibts dafür ja das BIOS. Seh ich das richtig, dass die Pandora dann auch irgendeine Art feste Firmware / BIOS braucht?

Oder kennt der ARM auf dem OMAP erstmal nur den internen NAND und lädt von da das OS. Das würde bedeuten, dass diverse Bootmanager und Lowlevel-Geschichten beim Angström mit drinstecken, und dieses die Funktionen des BIOS mit übernimmt. Allerdings wärs dann doof, wenn man den NAND komplett formatiert, weil dann dem ARM der Einsprungpunkt fehlt und sich auch nicht wiederherstellen ließe.

Also, gibt es ein BIOS / eine Firmware, was kann die, welche Aufgaben hat sie, welche das OS, lässt sich das Updaten?

 

[retn]

Hallo,

es gibt einen Bootmanager(?) namens U-Boot der die Firmware von NAND bzw alternativ von der SD-Karte lädt.
Der lässt sich auch updaten.
Ob das beim Systemstart noch die Hardware checkt weiß ich nicht.

Gruß,

retn

 

[relei]

Hi,

nein der Uboot macht keinen Hardware-Check, das macht dann erst der Kernel. Im uBoot muss man wissen was da ist oder was nicht da ist.

Schönen Gruß
Rene

 

[retn]

Das heißt uBoot macht nichts anderes wie ein normaler Boot-Manager ala Grub/Lilo.
Nur in abgespeckter Version halt?

 

[relei]

Ja genau, ich glaube der uBoot hat so um die 20-30 Befehle und das wars. Das toole ist das man den uBoot wirklich sehr leicht anpassen kann, um so z.B. ein Boot-Menu anzeigen zu lassen.

 

[Emu&Co]

Initialisiert der nicht den RAM? Zumindest war das bei der nSLUG so, dass der Bootloader den RAM festlegte und wenn man mehr einlötete, musste der ersetzt werden.

 

[relei]

Hi,

ich bin mir jetzt nicht ganz sicher, aber ich meine nicht. Denn der uBoot greift direkt auf Adressbereiche zu... glaube ich.

Schönen Gruß
Rene

 

[matzesu]

Alle die jetzt nichts verstanden haben heben die Hand und Winken :nope: :nope: :nope: :lol: (sorry, das musste sein..)

"Wir leben alle auf einem Gelben Uboot"

 

[subnet_zero]

Erklärung Wikipedia: http://de.wikipedia.org/wiki/Bootloader
uboot in der DBox: http://wiki.tuxbox.org/Bootloader
Doku uboot: http://www.denx.de/wiki/U-Boot

Ich hoffe das hilft etwas vom Trip mit dem gelben Uboot wegzukommen...

 

[xyta]

Gut aber ein Bootloader liegt ja immer schon auf dem Datenträger vor, von dem gestartet wird. Dazu muss der Prozessor ja dann wissen, dass es diesen Datenträger gibt. Irgendwer muss dem Prozessor ja sagen, wo er nach dem Starten anfangen soll, Code zu laden.

Auch soll es ja möglich sein, von SD-Karte oder USB zu starten.

Läuft das dann hier so:

1) Eine fest verbaute Schaltung im OMAP sagt dem ARM-Core, dass er grundsätzlich vom NAND starten soll

2) Im NAND befindet sich dieses UBoot , was so programmiert ist, das der ARM entweder weiter vom NAND das OS startet, oder je nach Geschmack auch von USB, SD1 oder SD2.

Dann wär die Frage, was passiert, wenn man den NAND komplett formatiert. In PC-Worten gesprochen hätte man damit nämlich auch den BIOS-Baustein gelöscht...
Der ARM würde immer im NAND nachschauen, aber dort dann nichts mehr finden, und es gäbe wohl auch keine Möglichkeit mehr ohne OS und UBoot da was reinzuschreiben...

 

[relei]

Hi,

naja es funktioniert so das der Prozesser an einer bestimmt Stelle nach sieht ob da was ist. Sagen wir im NAND und wenn er da was findet dann läd er das, im unserem Fall den uBoot. Sollten wir nun aus lauter Spaß den NAND löschen (wie ich beim Beagleboard), dann kann man diesen über den UART direkt neu beschreiben und alles ist wieder gut :-D .

Siehe hier:

http://wiki.beagleboard.de/index.php/Wiederbelebung

Schönen Gruß
Rene

PS: zu 2. die boot Reihen folge kann man dann mittels des uBoots aussteuern... z.b. in den man irgendwelche Tasten beim Start abfragt und wenn die richtige gedrückt wird dann kommt z.B. das Boot-Menu.

 

[xyta]

Gut, d.h. nach einem Löschen des NAND wäre noch nicht alles verloren.

Dennoch scheint es dann beim Beagleboard ja sowas wie eine untergeordnete Firmware zu geben; nämlich einen Speicher, in dem der serielle Terminalserver installiert ist, unabhängig vom NAND. Ist der Flashbar, was kann der, und was liegt da noch alles drin?

Bzw. bräuchte die Pandora warscheinlich keinen Terminalserver, da sie ja eine Tastatur hat. Aber irgendwo scheint ja ein Programm zu sein, was Daten von der SD-Karte wieder ins NAND kopieren kann und Meldungen

Downloading file: 100.000% completed(162656/162656 bytes)
File Download completed

ausgibt.

Wo befindet sich bei der Pandora eigentlich die User-Taste? ??

 

[Anonymous]

Läuft das dann hier so:

1) Eine fest verbaute Schaltung im OMAP sagt dem ARM-Core, dass er grundsätzlich vom NAND starten soll

2) Im NAND befindet sich dieses UBoot , was so programmiert ist, das der ARM entweder weiter vom NAND das OS startet, oder je nach Geschmack auch von USB, SD1 oder SD2.

Das läuft ziemlich genau so. Die "fest verbaute Schaltung" ist der i²c-Bus. Das ist ein serieller Bus, den so ziemlich jeder etwas komplexere Digitalchip unterstützt und über den Chips u.a. ihre Identität und sonstige Parameter nach außen bekannt geben können. Nach dem Aufwachen fragt der Prozessor über den i²c-Bus erst einmal in die Runde, wer denn da so in seiner Umgebung vorhanden ist. Und bekommt über den i²c dann die Startadresse für den auszuführenden Code benannt. Der Code wäre dann der Bootloader, der erst einmal die rudimentären Funktionen des Gerätes einstellt und schließlich einen Kernel sucht und lädt. Den Kernel kann er dann schon auf unterstützten Peripheriegeräten wie SD-Kartenleser, USB-Port, Netzwerkanschluss usw. suchen.

Prinzipiell wäre es möglich, auch den Bootloader zu löschen, so dass gar nichts mehr geht außer dem Neuprogrammieren des Bootroms über eine Hardware-Schnittstelle (sprich JTAG). Dagegen gibt es aber allerlei Maßnahmen: ein Flash-Chip ist nach dem Power-on gewöhnlich im read-only-Zustand, bevor da also der Kernel oder sonstwer nichts dran ändert, kann da auch nichts überschrieben werden. Das Flash wird zudem unter Linux als MTD verwaltet (Memory Technology Device). Üblicherweise wird das Flash partitioniert, so dass der Bootloader einfach in einer ersten Partition liegt, die schlauerweise ebenfalls nur read-only ist. Von daher müsste man sich schon ziemlich anstrengen, um den Bootloader zu löschen oder zu überschreiben (unmöglich ist es definitiv nicht, aber kaum aus Versehen).

 

[Anonymous]

naja es funktioniert so das der Prozesser an einer bestimmt Stelle nach sieht ob da was ist. Sagen wir im NAND und wenn er da was findet dann läd er das, im unserem Fall den uBoot. Sollten wir nun aus lauter Spaß den NAND löschen (wie ich beim Beagleboard), dann kann man diesen über den UART direkt neu beschreiben und alles ist wieder gut

Dazu braucht es aber bereits einen Bootloader, um eine serielle Konsole zur Verfügung zu stellen. Beim Beagleboard scheint uboot als "sekundärer Bootloader" benutzt zu werden, der von einem ersten, rudimentären Bootloader gestartet wird. Es ist auch nicht unüblich, einen solchen rudimentären Bootloader in ein gesondertes kleines ROM oder EEPROM zu tun, uboot oder dergleichen dann in einer Partition auf dem MTD (siehe oben). Ist halt etwas luxuriös, in einer Massenproduktion würde man das vermutlich einsparen wollen.