www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wie MBR und Bootsektoren disassemblieren


Autor: klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

ich habe eine SD Karte bei der ich mir gerne den MBR und die 
Bootsektoren disassembliert ansehen möchte. Da das Embedded System eine 
ARM CPU hat, dürfte der ARM Befehlssatz verwendet werden. Mit objdump 
des ARM GCC compilers komme ich leider nicht weiter

Jemand eine Idee?

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
klaus schrieb:
> Da das Embedded System eine
> ARM CPU hat, dürfte der ARM Befehlssatz verwendet werden.

Was lässt Dich das annehmen? Warum sollte der ARM-Rechner das 
Boot-Verhalten normaler PCs nachahmen?

Autor: klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es handelt sich um dieses Board:

http://www.freescale.com/webapp/sps/site/prod_summ...

Der Mikrocontroller hat einen ROM Bootstrap der von verschiedenen Medien 
booten kann, u.a. MMC/SD Karte. Ich möchte rausfinden wie genau das 
abläuft. Es liegen mehrere SD Karten bei auf denen unterschiedliche OS 
sind. Da jedesmal ein anderer Bootloader verwendet wird, liegt der 
Schluss nahe, dass der Bootloader auf SD Karte ist und nicht im internen 
Flash ist. D.h. der Bootstrap Code muss den Bootloader irgendwie 
ausführen.

> Was lässt Dich das annehmen?
> Warum sollte der ARM-Rechner das Boot-Verhalten normaler PCs nachahmen?

Weil die SD Karten einen MBR samt Partitionstabelle sowie Bootsektoren 
haben. Ein Verfahren ähnlich zum PC wäre aus meiner Sicht logisch. Wobei 
mir aber durchaus aufgefallen ist, dass bei einer Karte der MBR (außer 
der Partitionstabelle) nur 00en enthält.

Autor: Marek Uistar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
klaus schrieb:
> Ein Verfahren ähnlich zum PC wäre aus meiner Sicht logisch.

Aber auch nur aus deiner. Für alle anderen wäre es unlogisch. Der 
Controller schaut einfach nach, ob auf der Karte was ausführbares steht 
und startet es gegebenenfalls. MBR, Bootsektoren usw. sind da völlig 
überflüssig.

Autor: klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marek Uistar schrieb:
> Der Controller schaut einfach nach, ob auf der Karte was ausführbares steht

Dann erklär mir bitte, wie man "schaut einfach nach, ob auf der Karte 
was ausführbares steht" genau programmiert. Denn das muss der Bootstrap 
Code des Controller ja tun.

Autor: Michael Buesch (mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Normalerweise liegt der Kernel des Betriebssystems entweder in einem 
speziellen Bereich des Speichermediums oder in einem bestimmten Pfad im 
Dateisystem. Letzteres setzt natürlich vorraus, dass der ROM bootloader 
das Dateisystem lesen kann.
Das der DOS MBR verwendet wird halte ich auch für extrem 
unwahrscheinlich.

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RTFM

Hört sich jetzt hart an, aber lies das ver... datenblatt dazu. da steht 
drinn, wie die ihr Programm von der SD Card bekommen, wie diese 
auszusehen hat, und wohnin das geschoben wird.

und wenn das der Baustein nicht mit seinem ROM Code macht, dann iregend 
ein Programm, das von wo anders herkommt. Datenblatt des Evabords bringt 
da dann ggf die erleuchtung.

Schon mal das Documentation part duchgekaut?

UBoot hört sich da schon verdammt verdächtig an.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Bootloaderei sieht so aus, wie ein üblicher Linux Bootvorgang.

Auf der Karte befindet sich für das pre-load Linux ein Image des 
Rootfilesystems (rootfs), ein Kernel und ein Demoprogramm. Beim Windows 
Demo wird es ähnlich sein.

Wie man die SD Karte mit Image/Kernel/Demo füllen kann, steht in der 
Doku zum Board evk16_imx51_Linux_DemoImage_ReadMe.pdf

Entsprechend kann man die SD Karte auch unter einem Desktop-Linux 
mounten und sich die Sachen dort ansehen.

Autor: klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Buesch schrieb:
> Normalerweise liegt der Kernel des Betriebssystems entweder in einem
> speziellen Bereich des Speichermediums oder in einem bestimmten Pfad im
> Dateisystem. Letzteres setzt natürlich vorraus, dass der ROM bootloader
> das Dateisystem lesen kann.
> Das der DOS MBR verwendet wird halte ich auch für extrem
> unwahrscheinlich.

Bin halt nur am überlegen: Die SD Karten haben Windows CE, Android und 
Ubuntu darauf. Die Dateisysteme sind entsprechend unterschiedlich: 
Ubuntu hat "Linux Native" während Windows CE auf nem FAT ist. Glaube 
nicht, dass der ROM bootstrap das alles unterstützt. Das wird wohl erst 
der eigentliche Bootloader machen (im Falle von Ubuntu wird offenbar 
Redboot verwendet). Von dem her bleibt die Frage: Wie wird dieser 
Bootloader gefunden und ausgeführt ?

Autor: klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
123 schrieb:
> RTFM
>
> Hört sich jetzt hart an, aber lies das ver... datenblatt dazu. da steht
> drinn, wie die ihr Programm von der SD Card bekommen, wie diese
> auszusehen hat, und wohnin das geschoben wird.
>
> und wenn das der Baustein nicht mit seinem ROM Code macht, dann iregend
> ein Programm, das von wo anders herkommt. Datenblatt des Evabords bringt
> da dann ggf die erleuchtung.
>

Ach weißt du 123, wer RTFM sagt sollte das FM zumindest selbst mal 
geelsen haben. Das FM für das i.MX51 EVK ist nämlich eine 
Hochglanzbrochüre in der steht wie man unter Ubuntu dann Gimp startet. 
Im Reference Manual zum MCIMX51 gibt es das Kapitel "System Boot". Das 
ist leider sehr oberflächlich und bringt einen bei der Frage nicht 
weiter. Da steht drin welche Fuses (bzw. GPIO overrides) gesetzt sein 
müssen, damit von MMC/SD Karte gebootet wird. Dann habe ich noch diverse 
andere Dokumente im Angebot, z.B. "i.MX51 EVK Hardware", "i.MX51 
Power-Up Sequence", "U-Boot for i.MX51 Based Designs" usw. Hätte ich die 
Antwort darin gefunden würde ich nicht fragen. Wenn du also ein FM hast 
in dem die Antwort steht poste bitte den Link.

> Schon mal das Documentation part duchgekaut?
>
> UBoot hört sich da schon verdammt verdächtig an.

Ubuntu wird hier mit Redboot geladen und nicht UBoot. Daneben möchte ich 
wissen wie der Controller dazu kommt diesen Bootloader (Redboot, UBoot, 
etc) auszuführen. Die Funktion dieses Bootloaders ist dann klar

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
klaus schrieb:

> Ubuntu wird hier mit Redboot geladen und nicht UBoot. Daneben möchte ich
> wissen wie der Controller dazu kommt diesen Bootloader (Redboot, UBoot,
> etc) auszuführen. Die Funktion dieses Bootloaders ist dann klar

Der Controller wird wie üblich einen Vektor/Adresse haben, der/die nach 
dem Power-on von der Hardware automatisch angesprungen wird. Diese 
Adresse wird üblicherweise zu dem Bootloader-Code im Flash führen. Diese 
Infos stehen üblicherweise im Hardware-Datenblatt des Controllers.

Der Code dort zieht dann den Rest des Systems hoch, also bei Linux den 
Kernel und das rootfs von der SD-Karte.

Den auf das EVB angepassten Bootloader-Code selbst (Redboot z.B.) kannst 
du als Dump (Speicherabbild) auf die SD Karte downloaden und 
disassemblieren. Einfacher dürfte es sein, wenn der Quellcode und die 
Doku des Bootloaders untersucht wird.

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok

die informationen von Frescale sind wirklich dürftig.
Und deine Frage hat sich so angehört, als würde da einer im trüben 
fischen ohne sich vorher schlau zu machen.

nachfolgenden hinweis hast du sicher auch gelesen?

NOTE
For detailed information about the boot module contact your Freescale
representative.

wobei die U-Boot documentation mehr auflschluss bringen könnte.

google: +iMx SD Card boot

http://www.mail-archive.com/u-boot@lists.denx.de/m...

+I use dd:
+
+dd if=u-boot.imx of=/dev/mmcblk0 bs=512 seek=2
+
+This command copies the u-boot image at the address 0x400, as required
+by the processor.
+
+Now remove your card from the PC and go to the target. If evrything 
went right,
+the u-boot prompt should come after power on.
+

scheint so zu sein, das der Bootsektor deiner SD-karte der Falsche punkt 
ist. Addresse 0x400 und folgend auf der SD - Karte sind entscheidend.

Step 1. interner BootCode wird geladen und ausgeführt.
Step 2. pining und fuse auswerten
Step 3. SD-Card Image 0x400 laden und ausführen

gruss

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Teilweise sieht man auf Boards, dass ein Pre-Bootloader installiert ist, 
der bestimmte Jumper auf dem Board abfrägt und je nach Stellung dann die 
weiteren Aufgaben ausführt, also z.B. einen Bootloader im Flash 
anspringt, einen Bootloader von SD-Karte zieht, einen Disgnosemodus 
startet usw.

Autor: klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
123 schrieb:
> scheint so zu sein, das der Bootsektor deiner SD-karte der Falsche punkt
> ist. Addresse 0x400 und folgend auf der SD - Karte sind entscheidend.
>
> Step 1. interner BootCode wird geladen und ausgeführt.
> Step 2. pining und fuse auswerten
> Step 3. SD-Card Image 0x400 laden und ausführen

Guter Tipp, vielen Dank! Das könnte es gewesen sein.

Bei 0x400 sieht man im Diskeditor in der Tat etwas das aus 
flash_header.s enstanden sein könnte (Sektor 0 war MBR, Sektor 1 nur 
Nullen)
94 07 F0 AF B1 00 00 00 00 00 00 00 14 04 F0 AF 00 00 00 00 1C 04 F0 AF 00
00 F0 AF E9 19 72 B1 A0 02 00 00 04 00 00 00 A0 88 FA 73 00 02 00 00 04 00 
00 00 0C 85 FA 73 C5 20 00 00 04 00 00 00 10 85 FA 73 C5 20 00 00 04 00 00 
00 3C 88 FA 73 02 00 00 00 04 00 00 00 48 88 FA 73 02 00 00 00 04 00 00 00 
B8 84 FA 73 E7 00 00 00 04 00 00 00 BC 84 FA 73 45 00 00 00 04 00 00 00 C0 
84 FA 73 45 00 00 00 04 00 00 00 C4 84 FA 73 45 00 00 00 04 00 00 00 C8 84 
FA 73 45 00 00 00 04 00 00 00 20 88 FA 73 00 00 00 00 04 00 00 00 A4 84 FA 
73 03 00 00 00 04 00 00 00 A8 84 FA 73 03 00 00 00 04 00 00 00 AC 84 FA 73 
E3 00 00 00 04 00 00 00 B0 84 FA 73 E3 00 00 00 04 00 00 00 B4 84 FA 73 E3 
00 00 00 04 00 00 00 CC 84 FA 73 E3 00 00 00 04 00 00 00 D0 84 FA 73 E2 00 
00 00 04 00 00 00 2C 88 FA 73 04 00 00 00 04 00 00 00 A4 88 FA 73 04 00 00 
00 04 00 00 00 AC 88 FA 73 04 00 00 00 04 00 00 00 B8 88 FA 73 04 00 00 00 
04 00 00 00 00 90 FD 83 00 00 A2 82 04 00 00 00 08 90 FD 83 00 00 A2 82 04 
00 00 00 10 90 FD 83 D0 D0 0A 00 04 00 00 00 04 90 FD 83 AB 84 35 33 04 00 
00 00 0C 90 FD 83 AB 84 35 33 04 00 00 00 14 90 FD 83 08 80 00 04 04 00 00 
00 14 90 FD 83 1A 80 00 00 04 00 00 00 14 90 FD 83 1B 80 00 00 04 00 00 00 
14 90 FD 83 19 80 44 00 04 00 00 00 14 90 FD 83 18 80 32 07 04 00 00 00 14 
90 FD 83 08 80 00 04 04 00 00 00 14 90 FD 83 10 80 00 00 04 00 00 00 14 90 
FD 83 10 80 00 00 04 00 00 00 14 90 FD 83 18 80 32 06 04 00 00 00 14 90 FD 
83 19 80 80 03 04 00 00 00 14 90 FD 83 19 80 40 00 04 00 00 00 14 90 FD 83 
00 80 00 00 04 00 00 00 14 90 FD 83

Werde mal versuchen es zu disassemblieren. Falls es wirklich der 
Flash-Header ist müßten die ersten Bytes einen Jump darstellen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.