Die nachfolgenden Beispiele sind auf allen TMPA9x0 basierten Boards mit U-Boot anwendbar.
Was wird benötigt?
OpenOCD konfigurieren
In einem aktuellen OpenOCD sind die benötigten Konfigurationsdateien für die TMPA9xx Boards und das Interface bereits enthalten. Erstellen Sie eine Konfiguration für OpenOCD (topas900-jlink.cfg) die folgende Zeilen enthält:
adapter_khz 1000 source [find interface/jlink.cfg] source [find board/topasa900.cfg]
Verwenden Sie die äquivalenten Bezeichnungen, wenn Sie kein TopasA900 verwenden.
OpenoOCD starten
openocd -f topas900-jlink.cfg
Es sollte eine solche Meldung zu sehen sein:
Open On-Chip Debugger 0.5.0 (2011-12-03-08:57) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html 1000 kHz Info : only one transport option; autoselect 'jtag' trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain adapter_nsrst_delay: 20 jtag_ntrst_delay: 20 dcc downloads are enabled Info : clock speed 1000 kHz Info : JTAG tap: tmpa900.cpu tap/device found: 0x07926031 (mfg: 0x018, part:0x7926, ver: 0x0) Info : Embedded ICE version 6 Info : tmpa900.cpu: hardware has 2 breakpoint/watchpoint units
U-Boot Images mit OpenOCD hochladen
Mit OpenOCD verbinden:
$ telnet localhost 4444 Trying 127.0.0.1... Connected to clarke. Escape character is '^]'. Open On-Chip Debugger
Mit folgendem Kommando das Board anhalten:
reset halt JTAG tap: tmpa900.cpu tap/device found: 0x07926031 (mfg: 0x018, part: 0x7926, ver: 0x0) target state: halted target halted in ARM state due to breakpoint, current mode: Supervisor
Nun muß das RAM initialisiert und die Images hochgeladen werden. Das Erste wird direkt aus dem RAM gestartet, das Zweite wird ins NAND-Flash installiert.
topasa900_init load_image /path/to/u-boot.bin 0x43f00000 load_image /path/to/u-boot_nand_topasa900.bin 0x40100000
Nun starten Sie den U-Boot im RAM:
resume 0x43f00000
Jetzt sollten auf der seriellen Konsole Ausgaben vom U-Boot zu sehen sein. Verwenden Sie folgende Kommandos um den zuvor hochgeladenen U-Boot ins Flash zu schreiben:
U-Boot> nand erase 0 0x80000 U-Boot> nand write 0x40100000 0 0x80000
Sie sollten eine Ausgabe wie diese sehen:
NAND write: device 0 offset 0x0, size 0x80000 524288 bytes written: OK
Nun überprüfen Sie ob das Board zum Booten aus dem NAND konfiguriert ist.
Alle DIP-Schalter ausser SELJTAG (2.) müssen auf "aus" stehen (oben).
Starten Sie das Board neu (entweder mit der reset-Taste oder OpenOCD).
Die nachfolgenden Beispiele laden per TFTP-Protokoll über ein angeschlossenes Netzwerk die entsprechenden Dateien in das RAM des Boards. Dazu muß im Netzwerk ein TFTP-Server vorhanden sein. Die Standardeinstellung des U-Boot sieht vor, daß der Server die IP-Adresse 192.168.1.1 und das Board die IP-Adresse 192.168.1.2 verwenden. Um andere Adressen zu verwenden können im U-Boot Environment die Variablen "ipaddr" und "serverip" entsprechend umgesetzt werden, bspw.:
U-Boot> setenv ipaddr 192.168.41.42 U-Boot> setenv serverip 192.168.41.43
Es ist auch möglich die Netzerkeinstellungen per DHCP zu machen (s.u.).
Um die Einstellungen persistent über einen Reset des Boards hinweg zu speichern, muß das Environment wieder in das Flash geschrieben werden:
U-Boot> saveenv
Zur weiteren Vorbereitung müssen die notwendigen Dateien in das TFTP Verzeichnis des Servers kopiert werden.
U-Boot gibt folgendes Paritionslayout für das NAND-Flash vor:
device nand0, # parts = 5 #: name size offset mask_flags 0: u-boot 0x00060000 0x00000000 0 1: u-boot_env 0x00020000 0x00060000 0 2: splash 0x00300000 0x00080000 0 3: kernel 0x00300000 0x00380000 0 4: rootfs 0x0f980000 0x00680000 0
Die Partitionsnamen wie "splash", "kernel", etc. können bei den Flash Zugriffsbefehlen wie "nand erase" oder "nand write" symbolisch verwendet, bspw. löscht folgendes Kommando den kompletten Inhalt der Partition mit dem Namen "splash":
U-Boot> nand erase splash
Das Kernel Image "uImage" wird per TFTP Protokoll über das Netzwerk geladen und anschließend in die NAND Flash Partition "kernel" geschrieben. Verwenden Sie in den folgenden Kommandos "dhcp" anstatt "tftp", wird das Netzwerk-Interface zuvor per DHCP konfiguriert.
U-Boot> tftp uImage U-Boot> nand erase kernel U-Boot> nand write 0x40600000 kernel
Sinngemäß wird ein root-Dateisystem-Image per TFTP über das Netzwerk geladen und anschließend in die "rootfs" NAND-Flash Prtition geschrieben:
U-Boot> tftp root-filesystem-image.jffs2
U-Boot> nand erase rootfs
U-Boot> nand write 0x40600000 rootfs 0x${filesize}
Das U-Boot Environment enthält einen Parameter der bestimmt, welche Art von Root-Dateisystem woher verwendet werden soll - "rootfs_base". Diese Variable enthält standardmäßig folgenden Wert:
U-Boot> printenv rootfs_base
rootfs_base=setenv rootfs ${rootfs_jffs2}
U-Boot> printenv rootfs_jffs2
rootfs_jffs2=root=/dev/mtdblock5 rootfstype=jffs2
Diese Einstellung bedeutet, daß der Linux Kernel in der Partition Nr. 5 ein JFFS2 Dateisystem vorfindet. Soll dies bspw. auf UBI geändert werden, können folgende Befehle verwendet werden:
U-Boot> printenv rootfs_ubifs
rootfs_ubifs=ubi.mtd=5 root=ubi0:rootfs rootfstype=ubifs
U-Boot> setenv rootfs_base setenv rootfs \$\{rootfs_ubifs\}
U-Boot> saveenv
Die Backslashes vor dem "$" und den geschweiften Klammer "{}" sind nötig, damit U-Boot den Ausdruck nicht exandiert. Anschließend sollte die Variable "rootfs_base" folgenden Wert enthalten:
U-Boot> printenv rootfs_base
rootfs_base=setenv rootfs ${rootfs_ubifs}
Hint: aktuelle U-Boot Releases komen mit praktischen Skripten die die INstallation vereinfachen. Dazu dienen die Kommandos "run update_rootfs" und "run update_kernel".
Hinweis: Die Größe des ladbaren Images ist durch die Größe des vorhandenen RAM beschränkt! RAM-Start liegt bei Adresse 0x40000000, der U-Boot läuft aus dem RAM und liegt mit seinem Stack am Ende des RAMs. Bei bspw. 64MB RAM stehen für Daten noch ca. 50-55MB zur Verfügung. Wenn größere Inhalte geschrieben werden müssen, kann das ELDIO Tool verwendet werden.
last modified: 24. Mai 2013, 15:18
Anmelden
| PyLucid v0.9.0.0421