You are not logged in.

61

Monday, February 2nd 2015, 6:56pm

Ok werde mir dann die Daten u. Adressen anschauen, kann nur ein bischen dauern. :whistling:



Gruß Resident0007 ;)

62

Friday, February 13th 2015, 1:36pm

Hi Murphy-09,
Nach dem Einschalten sind alle Adressen auf low
DQ 0=high 1+2=low 3=high 4-15=low


MfG: Resident0007

63

Saturday, February 14th 2015, 10:50am

...na ja, beim Flash ist D15 das MSB und D0 das LSB, also würde das bedeuten: 0x0009, was kein sinnvoller Einsprung ins Flash wäre. Sofern dies der Datenwert am Ende des ersten Zugriffs darstellt, ist der Flash-Inhalt korrupt. Immer unter der Voraussetzung, dass kein anderer Baustein auf dem Datenbus das NOR blockiert, was man u.U. an Zwischenpegeln erkennen würde. Ist das NOR und somit der Bootloader defekt, sind in der Kiste die Lichter aus, und zwar total. Deshalb rate ich immer von vorschnellen Bootloader-Updates ab, denn ein kleiner Fehler beim Flashen und aus ist's mit der Kiste. Nun gut, wenn man also sicher ist, das so nichts mehr geht, hängt es von den Möglichkeiten ab, die man hat. Wer einen Programmer für parallele Bausteine sein eigen nennt, kann versuchen das TSOP auszulöten, über einen Adapter oder TSOP-Sockel im Programmer komplett auszulesen und zu retten, was zu retten ist. Der Bootloader ist hier das Unwichtigste. Zuerst geht es um Board-IDs, Seriennummern und MAC-Adressen, die im NOR verankert sind. Hier wäre mal die Address-Map:
flash0.avail0 New CFI flash at 1FC00000 offset 00000000 size 0KB
flash0.cfe New CFI flash at 1FC00000 offset 00000000 size 512KB
flash0.splash New CFI flash at 1FC00000 offset 00080000 size 2048KB
flash0.macadr New CFI flash at 1FC00000 offset 00280000 size 512KB
flash0.nvram New CFI flash at 1FC00000 offset 00300000 size 512KB
flash0.bootconfig New CFI flash at 1FC00000 offset 00380000 size 256KB
flash0.facconfig New CFI flash at 1FC00000 offset 003C0000 size 256KB
Dann braucht man natürlich den HEX-Dump einer vergleichbaren Box und nun kann man versuchen, das korrupte Flash zu patchen. Das Hauptproblem wird in einer Checksumme liegen, die vermutlich über dem Ganzen erzeugt wurde und ohne die ein zum Original geändertes Flash nicht akzeptiert werden wird. Das NOR einer anderen Box einfach zu kopieren kann zwar klappen, dann gibt es aber eine doppelte MAC-Adresse im Netz. Diese MAC kann man aber über den CFE Bootloader ändern.
Du siehst, das wird zwar keine unlösbare aber eher größere Aufgabe.
Eine weiter Möglichkeit wäre ein anderes Schrottboard zu erwerben und das NOR Flash einfach von dort zu entnehmen.

Da ich die Möglichkeiten habe, wäre mein erster Schritt, das NOR in einem anderen System, also Programmer oder CPU-System, auszulesen und mit einem gültigen Dump zu verifizieren.

Murphy-09 ;)

64

Tuesday, February 17th 2015, 9:42pm

Hi Murphy-09,

habe mal das Flash ausgelötet und auf einen Prommer gesteckt, bekomme dann folgende Meldung.
Die augelesene Chip Signatur passt nicht zum ausgewählten Chip (ausgewählt hatte ich S29GL032N90TFI04 so wie es auf gedruckt ist )

Erwartete Chip Signaturbytes 01h 227Eh 221Ah 2200h

Ausgelesene Chip Signaturbytes 00h 00h 00h 00h

Scheint wohl doch der Flash hin zu sein.

Meine frage ist noch wenn ich mir den Flash vom anderen ET9000 board nehme u. auf dieses Board auflöte, bekomme ich dann stress mit dem Secure-board?


MfG: Resident0007 ;)


PS: Danke nochmal für deine unermüdliche Hilfe :thumbsup:

65

Wednesday, February 18th 2015, 7:53am

Hi...

...da das Sec-Board einzeln zu haben ist, dürfte es keinen Unterschied machen. Und da Du ein NOR aus einem anderen Receiver nimmst, der ja eine gültige IP und Seriennummer hat schon zweimal nicht. Nun aber erst mal den Inhalt komplett sichern !

Murphy-09 ;)

66

Wednesday, February 18th 2015, 8:25pm

Hi,
wenn ich mir das andere NOR-Flash einlöte, muß ich ja denn aber mindestens die Seriennr. vom dem Board wo jetzt das NOR-Flash def. ist in das andere übertragen, denn sonst funktioniert es nicht mit dessen Secure_board oder brauch ich dann noch ein neues Secure-Board, denn mit dem anderem NOR-Flash habe ich ja denn eine andere Seriennr.

MfG: Resident0007

67

Thursday, February 19th 2015, 9:27am

...ich denke nicht, dass Du die Seriennummer ändern must. Das Sec-Board ist auch als Reparatur-Set einzeln erhältlich und hat keine Ahnung von der Seriennummer. Also Flash sichern, einlöten...starten.....

Murphy-09 ;)

68

Wednesday, May 20th 2015, 8:27pm

@Murphy-09
Unsuccessful boottlog looks like this
Shmoo Version=3.8
DDR Freq=0x0000018C
%00000001%
RC1=00000009
WC1=00000018
RC2=0000001F
WC2=00000038
RC3=00000014
WC3=0000001A
RC4=00000014
WC4=00000039
NWC=00000029
RC5=00000009
WC5=00000029
RC6=0000001F
WC6=00000029
NRC=00000014
RW=00000017
WW=00000020
G=00000000 R=00000014 W=00000029
BL=00000000
00000400
K6
F




Do you know what all RC1,WC1,RC2,WC2 ...and others mean? (I noticed that all unsuccessful bootlogs end with K6 and F. ).
If I understood properly , the unsuccessful booting( ending like that), can be cause also by the wrong DDR chip. Do you have any clue how to check if the DDR fault is the reason?

And the text of the bootlog is coming from NOR flash( =BIOS ??) or from CPU directly?
Thank you

69

Wednesday, May 20th 2015, 9:31pm

Hi Jane,

I'm not sure about the exact meaning of the RCs and WCs., but all this text comes out of the NOR Flash bootloader. The text shows the steps, how the NOR-Flash bootloader reads out the NAND-Flash blocks. At the successfull end, it performes a code compare and proves the checksum. If that's all o.k., it jumps into the NAND-Flash LINUX code and starts execution. In your case, the cpu stops the read out for any (unknown) reason. This might happen, in case a reset is caused by a voltage drop or the NOR-Flash itselfs has a problem with its contents or an electrical connection. The DRAM has also been set up to receive the unpacked NAND-Flash contents. If a stack or someting else is located within the DRAM at that Moment an d the DRAM has a problem, it also might cause this misbehaviour.
The boot process works in steps as follows:
Start executing instructions at 0xbfc00000 (boot flash, contains bootloader based on Broadcom CFE).
Initialize early boot console at UART0.
Basic CPU / system setup.
Start Broadcom CFE.
Search for flash image on external USB drive.
Offer flashing boot flash or NAND flash if flash image was found.
Load kernel in GZ compressed ELF format from NAND partition nandflash0.kernel.
Execute Linux kernel.
Load AES encrypted Broadcom drivers.
Run Enigma2 STB firmware.

Murphy-09 ;)

70

Wednesday, May 20th 2015, 10:12pm

Thank you for your reply.
If I understood well the booting failure can be caused by one of the four reasons;
Voltage drop
NOR chip ( BIOS)
NAND chip
DDR chip(s)
( CPU can be the fifth reason or not??)
Do you have any idea how to find the real reason from all those possibilities?
Thanks again for help

71

Wednesday, May 20th 2015, 10:47pm

Hi Jane,
that depends on your capabilities and equipment. If you have a digital scope, you may trace the NOR flash boot sequence and check out the NOR Flash signals for wrong Levels or steady signals. If the NAND chip fails, it would not cause that behaviour. The CFE bootloader, contained in the NOR flash, will always startup in the same way and, in case you stopped the boot sequence by some ^Cs, it will show the CFE prompt on the bootlog port. So the first thing to do, is to check out the different power rails, i.e. CORE, DDR and Peripherals. There should not be more that 50mV ripple on each rail and the voltages should not vary by more than 5% from ist reference value. If these Mainboard voltages are o.k., you have to check out the power-up-reset and the signals to the 48 pin TSSOP NOR device.
If you like to hear more, let me me know.......

Murphy-09 ;)

1 user apart from you is browsing this thread:

1 guests