Wie MBR und Bootsektoren disassemblieren

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.

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.

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.

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.

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 ?

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

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

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.