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.