Forum: Mikrocontroller und Digitale Elektronik Wie MBR und Bootsektoren disassemblieren


von klaus (Gast)


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?

von Rufus Τ. F. (rufus) Benutzerseite


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?

von klaus (Gast)


Lesenswert?

Es handelt sich um dieses Board:

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MCIMX51EVKJ

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.

von Marek Uistar (Gast)


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.

von klaus (Gast)


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.

von Michael B. (mb_)


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.

von 123 (Gast)


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.

von Stefan B. (stefan) Benutzerseite


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.

von klaus (Gast)


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 ?

von klaus (Gast)


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

von Stefan B. (stefan) Benutzerseite


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.

von 123 (Gast)


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/msg27797.html

+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

von Stefan B. (stefan) Benutzerseite


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.

von klaus (Gast)


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)
1
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
2
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 
3
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 
4
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 
5
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 
6
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 
7
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 
8
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 
9
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 
10
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 
11
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 
12
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 
13
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 
14
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 
15
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 
16
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 
17
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 
18
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 
19
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 
20
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 
21
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.

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
Noch kein Account? Hier anmelden.