Flash über JTAG lesen, Adressierungsfehler? | phyCORE MPC5200B tiny

[Flip B. (frickelfreak)]

Hallo zusammen,
ich brauche Hilfe beim Übertragen von Software auf den Flash eines 
Älteren SBC.

ich habe Geräte, die von einem SBC von phyTEC gesteuert werden. 
https://www.phytec.eu/en/support/downloads/phycore-mpc5200b-tiny/

Leider sind viele davon Hirntod, Booten nicht mehr, auch kein Output 
mehr auf dem UART. Kein Bootloader ansprechbar, nichts.

Auf dem Board ist ein 400MHz PowerPC MPC5200 und 512Mbit DDR DRam/ 
128Mbit Flash, ein paar Bustreiber, ResetChip, Spannungsregler, RTC, ETH 
Phy, EEprom. Durch kreuzweises tauschen auf zwei Boards konnte ich alles 
bis auf den MPC5200 und den Flash als Fehlerursache ausschließen 
(OK-Board bootet nach Tausch weiterhin, NOK bootet immernoch nicht)

Den Flash (PC28F128P33B, EZBGA64) habe ich auch umgelötet, danach 
funktionierte kein Board mehr. Wieder zurückgetauscht, dann 
funktionierte das OK-Board wieder. (Lötfehler will ich hier nicht 
ausschießen)

Mein nächstes Ziel war es nun, den Flash-inhalt auszulesen und auf das 
tote Board zu flashen.
Mit einem Altera USB-Blaster-Clone habe ich JTAG zum laufen gebracht, 
schnell UrJTAG kompiliert und komme auf den MPC5200 (Siehe 
Detect_Bus.png), Laut der U-Boot konfig von phyCORE habe ich einen muxed 
25b address, 16b data bus erwartet und den flash auf 0xFF00 0000

UrJTAG kann mit den einstellungen den Flash-chip jedoch nur auf Addr 0x0 
detectieren, lesen und schreiben. Das erzeugte Image ist 16MiB groß, ab 
0x74A00 nur noch FFFF, enthält plausible daten, viele Strings aus dem 
Menu des betreffenden Geräts in allen sprachen, jedoch  definitv kein 
U-Boot und keinen Linux Kernel. Hat da der Hersteller eine 
Baremetal-Anwendung auf den SBC geladen?

Firmwareupdates von REFUsol zum 802R020 konnte ich keine finden, damit 
könnte ich nachschauen, ob ~500kB hinkommen.

[Flip B. (frickelfreak)]

Zu bemerken ist, dass im ausgelesenen Image aller defekten module alle 
512Byte 16Bit 0x0000 sind, ansonsten sind die Images der 
funktionierenden module Bitgleich (offensichtlich selbe SW Version)

Schreibe ich den Dump aus einem OK-Modul in ein defektes, dann bootet 
dieses leider immer noch nicht. Zurücklesen/Verifizieren kann ich, Image 
ist dann OK. Kann da ein defekter Bonddraht im Prozessor sein?  3 
Defekte module haben jedoch denselben Fehler!?

[Dieter S. (ds1)]

Setzt UrJTAG denn die Chip Select Leitungen so wie es die für die 
Hardware richtig ist?

Ich denke das muss man selber machen, siehe "IPBI Control Register and 
Wait State Enable" im Datenblatt, speziell auch  das Bit "Boot Enable".

[Frank K. (fchk)]

Ich denke, es ist erfolgsversprechender, das Flash extern in einem 
Programmer auszulesen und in neue Flashes zu kopieren. So kann der Chip 
isoliert getestet werden, und Probleme auf der Leiterplatte können 
ausgeschlossen werden. Eventuell kannst Du Dir noch weitere Exemplare 
des Flash-Chips besorgen.

Die letzte Möglichkeit wäre, die Module zu Phytec zum Test zu schicken. 
Das werden die sicher nicht für lau machen, aber das hängt dann von 
Deinen Schmerzen ab.

fchk

[Flip B. (frickelfreak)]

Dieter S. schrieb:
> Chip Select Leitungen so wie es die für die Hardware richtig ist?

Guter Punkt. Ich dachte zuerst, das hat ja keinen einfluss, da die 
Register nicht persistent sind. Aber wenn ich sie zum flash lesen und 
schreiben modifiziere, dann bekomme ich ggf mehr aus dem flash, denn 
nach dem reset ist Boot stop adress 0x80000.


Den Flash chip kann ich momentan schlecht kontatieren, da BGA. Habe hier 
einen TL866II Pro, der unterstützt nicht offiziell diesen flash, aber 
das ist einfacher paralell-adressierter flash oder?

Adapter habe ich nur für TSSOP und fädeldraht am BGA64 wird eine 
herausforderung. Aber ich bestelle mal einen Adapter.

[Dieter S. (ds1)]

Was ist mit dem "Backup" U-Boot (siehe phyCORE-MPC5200B tiny Hardware 
Manual), funktioniert das eventuell noch?

[Flip B. (frickelfreak)]

Dieter S. schrieb:
> Was ist mit dem "Backup" U-Boot

Boot Pin auf HIGH bringt leider keinen Boot-Output. Darum meine annahme, 
dass der Gerätehersteller vielleicht alles gelöscht und ein 
Monoltithisches Baremetal Software einsetzt. Dazu passt nur nicht die 
ca. 15s Bootzeit.
Jedoch könnte ich, wenn ich ein U-Boot Binary finde, das mal in den 
Flash schreiben und schauen wie ich weiterkomme.

Ich probiere gerade MBAR zu finden und CS0 Stop adress zu ändern. Aber 
in  0x8000 0000  (init MBAR addr) steht nicht 0x0000 8000  sondern 
0x0000 auch wenn ich was anderes reinschreibe

[Dieter S. (ds1)]

Flip B. schrieb:
>
> Ich probiere gerade MBAR zu finden und CS0 Stop adress zu ändern.

MBAR steht beim e300 in SPR311 (Special-purpose Register). Ich würde 
erwarten dass UrJTAG auf die SPRs zugreifen kann.

[Flip B. (frickelfreak)]

Ich habe neuigkeiten. Ich habe den flash bisher auf dem zugehörigen 
Motherboard aus dem Wechselrichter gelesen. Dort ist noch ein FPGA, der 
offensichtlich mit am Bus hängt. Nun habe ich in höheren Flash-bereichen 
noch mehr Daten gefunden, die jedoch nach Müll aussehen. Eventuell der 
Config-Bitstream aus dem FPGA?

Ich lasse wohl nochmal ein  komplettes Flashdump laufen, dauert leider 
mit meinem setup ca. 5h30min

[Flip B. (frickelfreak)]

Hier das FPGA-Motherboard

[Flip B. (frickelfreak)]

Ohne Motherboard komme ich an alle Flashbereiche und bekomme plausible 
daten raus. Im höchsten Block liegt den strings zufolge ein U-Boot. Ich 
kann jedoch nicht mehr als 0x100000 (1MByte) am stück lesen, sonst kommt 
nur noch FFFF. Eventuell hat das auch gar nichts mit dem Motherboard zu 
tun, nur ein Bug im UrJtag flash treiber.

[Dieter S. (ds1)]

Der FPGA auf dem Motherboard könnte im Adressraum des MPC5200B eigene IO 
Register einblenden. Unter der Annahme dass der FPGA nicht defekt ist 
stellt sich die Frage ob UrJTAG eventuell den Flash falsch erkennt weil 
es durch den FPGA im Adressraum durcheinander kommt.

[Flip B. (frickelfreak)]

ich habe jetzt  einen kompletten dump eines OK board sowie U-Boot von 
einem NOK modul gelesen. Das Image vom NOK hat die gleichen defekten 
0x0000 bytes wie ich im niedrigeren Adressraum beibachtet hatte.

Überschreiben des U-Boot klappt schonmal, das ursprünglich defekte Board 
lässt schonmal die Boot-Leds blinken. Jetzt ist vermutlich noch das 
jiffs defekt, das möchte ich aber über uboot uart überschreiben, hoffe 
das geht schneller.

[Flip B. (frickelfreak)]

Ich konnte ein Gerät wiederbeleben, hielt leider nicht lange. 2x Booten 
und es war wieder tot. Werde jetzt mal neue Flash-Chips bestellen.

[Michael R. (netadair)]

Auf dem Board läuft MQX von NCP ....

[Michael R. (netadair)]

Ich habe einen BDI2000 mit bdigdb cop 1.33 drangeklemmt; das ist das lt. 
Phytec auch das Gerät, dass vor ~20 Jahren bei der Entwicklung benutzt 
wurde. Netterweise bekam ich auch die cfg für das Modul, hatte selber 
ein paar Probleme mit dem Setup des SDRAM-Controllers, fehlten wohl ein 
paar Bits in meiner cfg.
Praktischerweise haben die alten SR-Boards bis 2.07 noch eine schöne 
2.54mm-JTAG-Wannenbuchse. Mit dem 2mm-Anschlüssen komme ich nicht weit, 
finde keine passenden Stecker dafür.

Das Debugging ist etwas mühsehlig, der Prozessor scheint in eine 
Endlosschleife bei 0xfff0b4f0 zu geraten. Hab's dann erstmal gelassen...
Allerdings war es kein Problem, inzwischen fünf Module zumindest im 
Trockenen an einem PMU-Board wieder an's Fliegen zu bekommen.
Flash löschen und ein komplettes Image drüberflashen. Hatte da vorher 
noch das Datlog frisch formattiert.

Ich muss die noch im WR selber prüfen, und vielleicht auch eine Zeitlang 
im Labor laufen lassen ("hielt leider nicht lange. 2x Booten") ...

Meine Vermutung ist, dass wir sowas wie "over erasure" auf dem NOR-Flash 
haben. Das scheint zumindest eine gute Erklärung für seltsame Korruption 
im Flash.
Die korrupten Daten habe ich runtergeladen, muss mal schauen, ob sich da 
in der Breite ein ähnliches Muster von defekten Daten findet.

[Michael R. (netadair)]

Noch eine Erkenntnis: den Datlog-Bereich ab 0xff200000 kann man in 
128kB-Blöcken löschen, die der Chip neben den 32kB-Blöcken unterstützt.
Das klappt (am Anfang) des restlichen Flashbereich nicht; löschen von 
128kB scheint dort nur die ersten 32kB zu löschen.

[Jük P. (tik-tak)]

Was bekomm ich fürs auslesen und programmieren deines Flashes 
PC28F128P33B, EZBGA64?

[Michael R. (netadair)]

Nochmal eine Zwischenmeldung:
Ich habe jetzt 24 Module überprüft und neu geflasht; 7 davon waren 
wirklich defekt, SDRAM kaputt/nicht ansprechbar, Flash überhaupt nicht 
ansprechbar, und ein paar Flashspeicher mit versetzten Zugriffmustern 
(öfters 32bit breite Felder von meist 0x20, manchmal 0x10, früher aus 
dem Flash)
die anderen 19 scheinen zu funktionieren...

[Flip B. (frickelfreak)]

Ich lese gespannt mit. Hatte damals nach erfolglosem Tausch des Flash 
aufgegeben, da ich eventuell lose bonds im MPC vermutete, Aber SRAM ist 
auch eine Spur. Hast du die PN  mit meiner mailadresse bekommen? 
Vielleicht sind genau diese Module nun bei dir gelandet, wir können mal 
die MACs abgleichen.