-1

Ich habe eine MPC5200 v2.2, Core v1.4 auf einem phyCORE-MPC5200-tiny Board. DRAM 64 MB, FLASH 16 MB. RTOS VxWorks 6.9.Warum U-Boot (DENX) bleibt in der Boot-Schleife und gibt "Program Check Exception"?

Ich habe Probleme beim Booten des Embedded Systems und es bleibt in der Start-Schleife, wenn U-Boot/Uboot (DENX) versucht, Bild zu laden, sagen: "Programm Check Exception".

Zum Debuggen während der Entwicklung verwende ich einen TFTP-Server, um vxWorks binary direkt in den RAM zu laden (U-Boot-Befehl: 'tftpboot 0x100000 vxWorks.bin'). In diesem Fall funktioniert alles gut. Für die Veröffentlichung wird die reine * .bin VxWorks-Datei (Größe von 8,07 MB (8.462.808 Bytes)) komprimiert und in eine U-Boot-kompatible Image-Datei (mit Bootloader-spezifischen Header-Informationen) und einer resultierenden Größe von 5 verpackt. 25 MB (5.509.763 Bytes). Die Image-Datei wird auf Flash geladen, von wo sie unkomprimiert und in den Arbeitsspeicher geladen wird (U-Boot-Befehl: 'bootm 0xff800000'). Danach wird die oben genannte Ausnahme ausgelöst, was zu einem Neustart der Schleife führt (siehe Screenshot unten).

Ich habe bereits untersucht, ob das vorbereitete Bild eine Größe unter 5 MB hat, U-Boot lädt es ohne Fehler. Vielleicht könnte auch die unkomprimierte Dateigröße ein Problem sein ?! (Bei 8 MB?)

Haben Sie eine Idee haben, wie dieses Problem gelöst werden kann?

Quelle

2016-11-20 Chris

Veröffentlichen Sie keine Bilder von Text! – Olaf

Es scheint, dass das Problem aufgrund eines Grenzwerts von 8 MB in U-Boot bei Verwendung des Befehls bootm aufgetreten ist. Irgendwelche Ideen wie man dieses Bootlimit umgehen kann? – Chris

Ich habe untersucht, dass der scheiternde Punkt der nicht komprimierende Schritt von "bootm" ist. Über TFTP (und den Befehl 'cp') habe ich die unkomprimierte Binärdatei und das komprimierte Bild in den Flash kopiert. Dann habe ich noch einmal versucht, das komprimierte Image mit bootm zu booten. Nach dem erwarteten Absturz und Reset konnte ich die (durch 'bootm') unkomprimierten Daten im RAM mit den unkomprimierten binären Daten im Flash (mit dem Befehl 'cmp') vergleichen. Genau nach 8mb, stimmen die Daten nicht mehr überein! In einem zweiten Test habe ich ein unkomprimiertes Image erstellt, welches bootm ohne Probleme booten konnte. Irgendwelche Ideen? – Chris

U-Boot (seit 2011.06) bietet die Umgebungsvariable "bootm_mapsize", um den zum Booten des Kernel-Images erforderlichen Speicherplatz zu ändern.

Allerdings scheint Ihr U-Boot wirklich alt; & darf dies nicht enthalten.

In Ihrem U-Boot Ich verstehe, dieser Wert in gesetzt "include/configs /" Datei:

definieren CONFIG_SYS_BOOTMAPSZ (8 < < 20)/* Anfangsspeicherkarte für Linux */

Sie können diesen Wert & ändern, um U-Boot neu kompilieren, um über das Problem zu kommen.

Ich hoffe, das hilft.

Quelle

2016-11-25 12:09:06 rk1825

Danke für diesen Hinweis. Wir werden prüfen, ob es das Verhalten beeinflusst. Zunächst konnten wir feststellen, dass der obige Parameter in unserer Version nicht existiert, sondern stattdessen CFG_BOOTMAPSZ entspricht. – Chris

Warum U-Boot (DENX) bleibt in der Boot-Schleife und gibt "Program Check Exception"?

Antwort

definieren CONFIG_SYS_BOOTMAPSZ (8 < < 20)/* Anfangsspeicherkarte für Linux */

Verwandte Themen