Thema: JTAG SF1008HD SE+ (hs7810a)

Zitat von mkay

...
Wie schon geschrieben ist interessant, dass nach meiner Flash Aktion der Receiver funktioniert, wenn ich nur das Board mit JTAG initiallisiere und danach die Kontrolle an den Receiver übergebe (continue) Denn continue sagt gdb nur, dass es mit der Ausführung des geladenen Programmes beginnen soll. Da ich aber nichts mit load in den RAM geladen habe, hat der Receiver den original Bootloader während der Boardinitialisierung in den RAM geladen und nach dem eingetippten continue via JTAG gestartet.

Wenn ich dann in gdb folgendes mache:
- STRG + C (Unterbricht die Ausführung des Receiver)
- <gdb> ondisconnect restart (Was soll nach disconnect von gdb passieren? In meinem Fall mit der Ausführung am letzten Punkt weiter machen)
- <gdb> disconnect (Beende gdb Session via JTAG)
Kann ich den JTAG-Adapter entfernen und der Receiver verichtet über Stunden normal seinen Dienst. Nach Ausschalten an der Fernbedienung geht er in den Deep-Standby und die Uhr im Display erscheint. Nach wiedereinschalten sind dann alle LEDs aus und es erscheint keine Bootloadermeldung auf dem Display...

Wenn sich der Receiver so verhält, dann passt das geflashte u-boot.bin nicht richtig zum Receiver, weil dieses u-boot die Grundinitialisierung der internen Register des Receiver-Chips anders macht, als wenn man die Grundinitialisierung über JTAG mit der hdk7111 Target-Definition macht. Andere Möglichkeit wäre, dass das u-boot in einen anderen Adressbereich des Flash-Speichers gehört, weil vor dem u-boot direkt nach dem Einschalten des Receivers noch ein sogenannter "First-Stage Loader" im Flash-Speicher gestartet wird, der die Grundinitialisierung macht und danach u-boot startet. Kenne die Fortis Receiver nicht so gut, um genau sagen zu können, wie der Boot-Prozess bei diesen Receivern wirklich ist. Im einfachsten Fall hilft da nur ein kompletter Flash-Dump eines funktionsfähigen Receivers.

@mkay

Forum hast du gefunden ;-)

Zitat von mkay

- Darauf kommt auf der Seriellen-Schnittstelle u-boot und ich mache folgendes:
- loady (originale u-boot.bin hochladen)
- protect off 1:0-4 (Schreibschutz u-boot Bereich im Flash entfernen)
- erase 1:0-4 (Flash Bereich löschen)
- cp.b 0x80000000 0xa0000000 $filesize
- Danach habe ich geschaut, dass Flash und u-boot.bin übereinstimmen md 0xa0000000 0x100 (Der Ausschnitt von u-boot.bin und Flash stimmen überein)
- reset (Softreset des Receivers)

hast du wieder Schreibschutz gesetzt nach
cp.b 0x80000000 0xa0000000 $filesize


cp.b $load_addr 0xa0000000 $filesize
protect on 1:0-4






ich gehe da von das diene reciver enspricht optibox anaconda
und habe ich von andere forum auch eine Einleitung copy paste gemacht

Zitat von pagix0815

Yoo, Eisha hats schon ganz gut drauf.

Zitat von pagix0815

Ich mach alles seriell, man muß sich ja irgendwie selbst zu helfen wissen.
Auch den Loader schiebe ich seriell rüber mit ymoden per Hyperterminal.

loady
protect off 1:0-4
era 1:0-4
cp.b 0x80000000 0xa0000000 $filesize
protect on 1:0-4
reset

Danach sind die alten Bootargs auch wieder vorhanden, sofern Du vorher auf einer laufenden Box so gesichert hattest
dd if=/dev/mtd0 of=/var/u-boot.bin bs=128K count=2

Alles mit Vorsicht zu genießen, ohne jtag würde ich auch eher auf das nächste update hoffen.

Zitat von pagix0815

Moin Moin,
dann will ich das mal versuchen zu erklären.
Diese Methode gilt nur für den 1008SE+ und baugleiche Modelle.

Zitat von pagix0815

###

Benötigt wird:
1x 20 Pin Boardconnector zum löten 2,54mm
1x FT2232 oder FT4232 Dev Modul
1x Jumperwire Kabelsatz
1x Nullmodemstrippe fürs Terminal
Viel Geduld ...
unter xxx.stlinux.com sind gute Dokus zu finden für die ersten Schritte.
Im xxx.avi-plus.com Forum unter Repair Tips in electronic / Miscellaneous / software / Others -> ST40 / STb71xx JTAG interfacing
habe ich eine sehr gute pdf Anleitung für die Kabelbelegung und den Weg das FT Modul zur ST MicroConnect Box zu clonen gefunden.
--- loader auf lauffähiger box sichern - sofern noch möglich
sichern:
dd if=/dev/mtd0 of=/var/u-boot.bin bs=128K count=2
--- jtag via st40 toolbox, hdk7111 loader unter stlinux 2.4 erstellen, bekommt man auf Link nur für registrierte und freigeschaltete Mitglieder sichtbar.
--- wenn Du dich mit sts-tools:sts-tools auf Link nur für registrierte und freigeschaltete Mitglieder sichtbar. einloggst findest Du unter Products das Toolset für win und das targetpacket mit den ft treibern fürs modul.
--- unter windows dann wie folgt das ft2232 oder ft4232 Modul ansprechen
sh4xrun -t STMCLT1000A:sat7111:st40 -e c:\hdk7111\u-boot
--- bootloader hochladen per ymodem (hyperterminal) am Terminal
protect off 1:0-4
era 1:0-4
loady
cp.b $load_addr 0xa0000000 $filesize
protect on 1:0-4
reset

wenn es zur Fehlermeldung bei "cp.b $load_addr 0xa0000000 $filesize" kommt dann
mit "cp.b (*) 0xa0000000 $filesize" probieren.
(*) hier die loadadresse aus der hyperterminal ausgabe angeben - bei mir war es 0x80000000
--- args setzen
hab mühsam jede reihen einzeln ins terminal getippelt.

Code:

set bootdelay '3'
set baudrate '115200'
set board 'hdk7111_INPUT_CLOCK_RATE'
set targetname 'muso'
set bootcmd 'bootm  0xa0100000'
set hwnfconf 'setenv nwhwnet device:eth0,hwaddr:$ethaddr'
set nfsserverconf 'setenv nfs_server nfsroot=$serverip'
set ipconf 'setenv ipaddrcfg ip=$ipaddr:$serverip:$gateway:$netmask:sdk:eth0:off'
set cramfsbootargs 'run hwnfconf;run ipconf;setenv bootargs console=ttyAS0,115200 root=/dev/mtdblock3 rootfstype=squashfs $ipaddrcfg nwhwconf=$nwhwnet bigphysarea=5000 stb7111:eth0:off stmmaceth=msglvl:0,phyaddr:2,watchdog:4000,rxsize:16 loglevel=0'
set nfsbootargs 'run hwnfconf;run nfsserverconf;run ipconf;setenv bootargs console=ttyAS0,115200 root=/dev/nfs $nfs_server:/opt/STM/STLinux-2.3/devkit/sh4/target,nfsvers=2,rsize=4096,wsize=8192,nolock,tcp nwhwconf=$nwhwnet $ipaddrcfg stmmaceth=msglvl:0,phyaddr:2,watchdog:4000,rxsize:16 bigphysarea=5000'

Code:

set ethaddr '00:1e:b8:00:00:00'  <<<--- an die eigene mac anpassen
set ipaddr '192.168.1.200'
set serverip '192.168.1.100'
set updt_ker 'vfd LD;tftp 0x80000000 vmlinux.ub.cram;protect off 1:8-23;erase 1:8-23;cp.b 80000000 0xa0100000 $filesize;protect on 1:8-23;vfd _End'
set updt_boot 'vfd LD;tftp 0x80000000 u-boot.bin;protect off 1:0-1;erase 1:0-1;cp.b 0x80000000 0xa0000000 $filesize;protect on 1:0-1;vfd _End'
set updt_boot_all 'vfd LD;tftp 0x80000000 u-boot.bin;protect off 1:0-255;erase 1:0-255;cp.b 80000000 0xa0000000 $filesize;protect on 1:0-255;vfd _End'
set updt_img 'vfd LD;tftp 0x80000000 root.img;protect off 1:104-191;erase 1:104-191;cp.b 80000000 0xa0d00000 $filesize;protect on 1:104-191;vfd _End'
set updt_dev 'vfd LD;tftp 0x80000000 device.img;protect off 1:192-215;erase 1:192-215;cp.b 80000000 0xa1800000 $filesize;protect on 1:192-215;vfd _End'
set updt_app 'vfd LD;tftp 0x80000000 app.img;protect off 1:24-63;erase 1:24-63;cp.b 80000000 0xa0300000 $filesize;protect on 1:24-63;vfd _End'
set updt_appb 'vfd LD;tftp 0x80000000 app.img;protect off 1:64-103;erase 1:64-103;cp.b 80000000 0xa0800000 $filesize;protect on 1:64-103;vfd _End'
set updt_user 'vfd LD;tftp 0x80000000 user.img;protect off 1:224-255;erase 1:224-255;cp.b 80000000 0xa1c00000 $filesize;protect on 1:224-255;vfd _End'
set erase_config 'protect off 1:216-223;erase 1:216-223;protect on 1:216-223'
set erase_env 'protect off 1:2-2;erase 1:2-2;protect on 1:2-2'
set stdin 'serial'
set stdout 'serial'
set stderr 'serial'

saveenv
printenv
reset
--- box sollte nun wieder im bootloader stehen und via usb flashfähig sein


Anmerkung: Das um232h Modul habe ich nicht zum laufen bekommen, st40 toolbox unter win meldete immer unbekannten chip. Unter Linux mag das anders aussehen.

Wenn sich der Receiver so verhält, dann passt das geflashte u-boot.bin nicht richtig zum Receiver, weil dieses u-boot die Grundinitialisierung der internen Register des Receiver-Chips anders macht, als wenn man die Grundinitialisierung über JTAG mit der hdk7111 Target-Definition macht. Andere Möglichkeit wäre, dass das u-boot in einen anderen Adressbereich des Flash-Speichers gehört, weil vor dem u-boot direkt nach dem Einschalten des Receivers noch ein sogenannter "First-Stage Loader" im Flash-Speicher gestartet wird, der die Grundinitialisierung macht und danach u-boot startet. Kenne die Fortis Receiver nicht so gut, um genau sagen zu können, wie der Boot-Prozess bei diesen Receivern wirklich ist. Im einfachsten Fall hilft da nur ein kompletter Flash-Dump eines funktionsfähigen Receivers.

Das ist prinzipiell auch meine Vermutung. Allerdings ist das wie gesagt das original u-boot image vom Hersteller und habe schon verschiedene u-boot Images in der Vergangenheit via RS232 geflashed und hatte nie Probleme. Mit dem ST Micro Toolset habe ich mir mal ein eigenes "Bootimage" gebastelt, bei welchem ich eine bootvector.img und bootstrap.img Datei vor das u-boot gehängt habe. Das hat leider auch nicht geklappt.

Ich habe hier noch einen anderen Receiver gleichen Typs, welcher funktioniert und wenn ich in u-boot folgendes eingebe:

Code:

hdk7111> md 0xa0000000 0x100

stimmen die angezeigten Flashbereiche überein. Aus der ST40 Micro Toolset Dokumentation habe ich auch die Information, dass der Receiver nach einem Reset an Addresse 0xA0000000 im Flash anfängt zu laden... so langsam gehen mir die Ideen aus.

@cobramostar:
Ja der Schreibschutz wurde gesetzt nach dem erfolgreichen flashen. Hatte ich vergessen mit aufzuschreiben...
Die Anleitung kenne ich bereits. Und genau so bin ich vorgegangen. Außer, dass ich das UM-FT2232H Modul, welches auch rimini benutzt hat, ebenfalls nutze.

Edit: Info, dass Schreibschutz gesetzt worden ist

Zitat von mkay

...
Ich habe hier noch einen anderen Receiver gleichen Typs, welcher funktioniert und wenn ich in u-boot folgendes eingebe:

Code:

hdk7111> md 0xa0000000 0x100

stimmen die angezeigten Flashbereiche überein. Aus der ST40 Micro Toolset Dokumentation habe ich auch die Information, dass der Receiver nach einem Reset an Addresse 0xA0000000 im Flash anfängt zu laden... so langsam gehen mir die Ideen aus.
...

Für ein richtig funktionierenden Bootloader kommt es nicht nur darauf an, dass der eigentliche Bootcode stimmt, gerade u-boot verwendet auch noch Environment-Variablen, die irgendwo im Flash-Speicher liegen können.

Wenn du einen baugleichen und funktionsfähigen Receiver besitzt, dann mach einen Dump des kompletten Flash-Speichers und nicht nur des Bootloaders, den man dann per JTAG auf dem defekten Receiver flashen kann. Das war/ist bei den Opticum 9500/9600 Receivern, die kein u-boot als Bootloader haben, die einzige Möglichkeit gewesen, die Receiver per JTAG wieder zum Laufen zu bekommen. Da der komplette Flash-Chip kopiert wird, sind das dann aber erstmal zwei komplett gleiche Receiver mit u.a. der selben MAC-Adresse, selber Serien-Nr. (falls das im Flash gespeichert ist) usw.

Entweder man kann beim funktionsfähigen Receiver mit dem dd-Befehl einen kompletten Flash-Dump erzeugen, wenn der Receiver ein Linux-System hat, oder man kann das per JTAG mit Hilfe des flasher-Tools von STmicro machen. Das u-boot selbst besitzt außer md leider keine Möglichkeit, Speicherbereiche zu dumpen. Das flasher-Tool von STmicro ist eine Beispiel-Anwendung, die als Source-Code mit den ST40-Tools mitinstalliert wird und findet man unter "C:\STM\ST40R5.1.0\sh-superh-elf\examples\os21" z.B. u.a. in der Beispiel-Anwendung rombootram. Zum Kompilieren muss auf dem PC ein Perl-Interpreter installiert sein (z.B. das freie ActivePerl für Windows).

Das eigentliche Problem bei dem flasher-Tool ist, dass dieses im Gegensatz zu u-boot nicht automatisch alle möglichen Flash-Chips richtig identifizieren kann. Die dem flasher-Tool bekannten NOR-Flash Chips und die zu verwendenden Lese-/Lösch-/Schreib-Routinen sind vielmehr hardcoded in den nor.h und norutil.c enthalten und müssen bei dort nicht vorhandenen, anderen Typen hinzugefügt werden. Um einen bestimmten NOR-Flash auszulesen/zu dumpen, reicht es, den Flash-Chip dort entsprechend zu definieren, ohne dass die Lösch-/Schreib-Routinen unbedingt passen müssen. Nur die Identifikations-Bytes und die Blockstruktur des NOR-Chips muss zum Dumpen (Auslesen) stimmen. Lese bei den Beispiel-Anwendungen unbedingt die readme.txt Dateien, da ist u.a. beschrieben, wie die Beispiel-Anwendungen kompiliert werden (müssen), was beim Kompilieren erzeugt wird und wie das flasher-Tool verwendet wird.

Wenn du einen baugleichen und funktionsfähigen Receiver besitzt, dann mach einen Dump des kompletten Flash-Speichers und nicht nur des Bootloaders, den man dann per JTAG auf dem defekten Receiver flashen kann. Das war/ist bei den Opticum 9500/9600 Receivern, die kein u-boot als Bootloader haben, die einzige Möglichkeit gewesen, die Receiver per JTAG wieder zum Laufen zu bekommen.

Jepp, genauso hab ich das bei diesen Receivertyp`s auch gemacht, dank Rimini`s Hilfe. Mit dem Flasher_Tool und einem richtig erzeugten "flasher.out" konnte ich einen Dump von einer funktionierenden Box machen. Dieses binäre Abbild habe ich dann per JTAG in den Receiver gespielt und die Geräte booteten danach dann wieder ohne Probleme.

Leider kann ich dann auch so nichts weiter dazu beitragen, da ich mich mit der Materie & diesen Receivern nicht auskenne. Bei mir steht erst noch das Kennenlernen mit Linux und das Komipilieren eines u-boot`s ins Haus. Da spielen ja viele Faktoren eine Rolle, was ich noch erlernen muss

Richtig, wenn der Bootloader denn zur Receiver-Hardware passt bzw. nicht auch noch den zu verwendenden seriellen Port des Receiver-Chips (bei den STi71xx-Chips gibt es da bis zu drei mögliche serielle Ports) für Bootmeldungen aus irgendeiner Variablen im Flash-Speicher wählt, weil der nicht hardcoded ist.

Nach dem geschilderten Verhalten des Receivers passt der Bootloader nicht 100%-ig zum Receiver.

Zitat von mkay

Genau das hatte ich mir vorgenommen und bereits besagtes Beispiel angeschaut (zufällig auch rombootram ). Und ich hatte genau das Problem, dass er meinen Flash speicher nicht erkannt hat. Das heißt ich muss nun zuerst versuchen meinen Flash Typ dort einzubringen, wofür deine Hinweise, was wo hin gehört sehr hilfreich waren, danke dafür Ich werde mal von beiden Receivern einen Dump anfertigen, damit man im Nachhinein die zuständigen Bytes identifizieren kann. Weil gerade schießen wir mit Kanonen auf Spatzen
...

Falls du Probleme hast, den im Receiver verwendeten Flash-Type in den Source-Code vom flasher-Tool hinzuzufügen, dann schreibe, welcher Flash-Chip genau im Receiver verwendet wird. Dann schau ich mir das auch mal an.

Anderes Problem mit dem Kompilieren eines zum Receiver passenden Flasher-Tools könnte es sein, dass im Source-Code diie Definitionen für den zu verwendenden hdk7111-Target fehlen. Übersehe ich gerade nicht, welche Targets im Source-Code definiert sind. Eventuell geht aber für die JTAG-Verbindung und damit auch für das flasher-Tool ein anderer, ähnlicher Target (z.B. mb618), der auch auf einem STi7111 basiert, zu verwenden und der im Source-Code des flasher-Tools vorhanden ist. Für das flasher-Tool ist es ja ausreichend, wenn die Grundinitialisierung nur die Takterzeugung und den Memory-Controller umfasst, denn den/einen seriellen Port usw. braucht man da gar nicht.

Falls du Probleme hast, den im Receiver verwendeten Flash-Type in den Source-Code vom flasher-Tool hinzuzufügen, dann schreibe, welcher Flash-Chip genau im Receiver verwendet wird. Dann schau ich mir das auch mal an.

Da ich das noch nie gemacht habe, geht es vermutlich schneller, wenn du mir Hilfestellung leistest:
Spansion S29GL256P90TFCR2 (Flash 256Mb 3.0-3.6V 90ns Parallel NOR Flash )

Anderes Problem mit dem Kompilieren eines zum Receiver passenden Flasher-Tools könnte es sein, dass im Source-Code diie Definitionen für den zu verwendenden hdk7111-Target fehlen

Ich denke, dass wir das Target hdk7111 einfach in den defines hinzufügen können sollten, da die Board-Definitionsdateien ja auch dort liegen, wo die "Basisboards" untergebracht sind, aber das werde ich direkt einmal testen...

Eventuell geht aber für die JTAG-Verbindung und damit auch für das flasher-Tool ein anderer, ähnlicher Target (z.B. mb618), der auch auf einem STi7111 basiert, zu verwenden

Da hast du recht, das sollte tatsächlich auch funktionieren. Ich melde mich, falls das gezielte bauen für hdk7111 nicht klappen sollte, dann können wir vermutlich immer noch auf mb618 ausweichen, welches ja auch stx7111 verwendet. Die genaue SoC Bezeichnung auf meinem Receivermainboard ist STi7110.

Aha, ST7110 ist wieder was anderes als ein STi7111. Die STi71xx basieren zwar alle auf einer SH4/ST40-Core und sind auch sonst alle irgendwie gleichartig, aber die Details der einzelnen Chips sind dann doch immer etwas unterschiedlich.

Mal sehen, welcher Target noch so zum STi7110 passen könnte und wie man den Flash-Chip soweit richtig in den flasher-Sourcen hinzufügt, dass der Flash-Chip zumindest über JTAG lesbar ist. Löschen und schreiben des Flash-Chips richtig zu definieren ist beim flasher-Tool schon etwas schwieriger bis unmöglich, wenn die passenden Routinen in den Sourcen fehlen sollten.

Schau ich mir heute alles etwas genauer an.

Datenblatt des Flash-Chips gibt es ja schonmal:

Link nur für registrierte und freigeschaltete Mitglieder sichtbar.