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