Thema: problem boot

@papaber

nütze bitte für deine Logs die Code-Funktion.

Zitat von papaber

...nur den setenv HOSTNAME LINUX7109 auf HOSTNAME LINUX7111 geendert...

HOSTNAME ist nur eine Name, wie der Receiver in einem Netzwerk als Name/Bezeichnung zu finden/identifizierbar ist. Da könnte sonstwas stehen.

Egal, das einzige, was mir noch einfällt, wäre den gesamten NAND-Flash, in dem die Kernel- und Firmware-Images gespeichert werden, zu löschen. Es gab mal einen Fall, da wurde durch das Flashen irgendeines Firmware-Images (könnte ein PKT-Image oder ein Backup-Image eines anderen, baugleichen Receivers gewesen sein) die Bad-Block-Table des Flash-Chips soweit verändert, dass auch nichts anderes geholfen hat:

Der NOR-Flash, mit dem u-boot Loader bleibt dabei unverändert, so dass man eigentlich nach dem vollständigen Löschen des NAND-Chips trotzdem wieder ein Spark-Rettungimage und dann ein Spark-Image flashen können sollte.

Also zunächst wieder das Autoboot von u-boot unterbrechen, so dass man u-boot Befehle eingeben kann. Dann den Befehl

nand bad

eingeben und alle Meldungen (die Bad-Block-Table) hier posten. Alle Blocks die dort mit 00 Bytes angezeigt werden, sind vom Hersteller als defekt markierte Blöcke. Bei größeren NAND-Chips können immer mal einige Blöcke defekt sein und als Ersatz gibt es ein paar Receiver-Blöcke. Die vom Hersteller als defekt markierten Blöcke dürfen auf keinen Fall vom Anwender verwendet werden, weshalb direkte Backups eines gleichartigen Receivers nicht in einen anderen Flash-Chip direkt geflasht werden können, ohne dass es zu Funktionsstörungen kommt. Die Flash-Chips werden normal anders mit Inhalten gefüllt, über MTD-Treiber und Dateisysteme, wobei die Bad-Blocks dann automatisch einfach übergangen werden und die reserve-Blocks 8falls nötig) verwendet werden. Genauso werden automatisch alle geflashten Blocks geprüft und falls der geflashte Inhalt nicht stimmt, wird der Block automatisch als defekt markiert Block. Diese Blocks erscheinen dann in der Bad-Block-Table mit ihren verfälschten Inhalten und können erstmal unbeachtet bleiben, da sie bei der nächsten Verwendung für Daten dann bei Fehlern wieder automatisch als defekt markiert werden.

Lange Rede, kurzer Sinn:

Poste die Terminal-Ausgaben von u-boot nach dem nand bad Befehl, dann sehen wir weiter. Bei dem Befehl wird nur die Bad-Block-Table des NAND-Chips gelesen und sonst nichts weiter verändert.

DAnke Rimini.ich habe es eingegeben,ob es so richtig ist?

Code:

MB618> nand bad
Device 0 bad blocks:MB618> save  
Saving Environment to Flash...Unprotecting Flash..... doneUn-Protected 2  sectorsErasing Flash..... done Erased 2 sectorsWriting to Flash........... doneProtecting Flash..... doneProtected 2  sectorsMB618> printbootdelay=3monitor_sec=0xa0000000    0xa007ffffethaddr=00:80:E1:12:06:38Exit=menuspark(up=key)enigma2(down=key)RS232=Upgrade u-boot(left key)Force=into factory mode(right key)nand=badbaudrate=115200board=mb618monitor_base=0xA0000000monitor_len=0x00080000load_addr=0x80000000unprot=protect off $monitor_secupdate=protect off $monitor_sec;erase $monitor_sec;cp.b $load_addr $monitor_base $monitor_len;protect on $monitor_secHOSTNAME=LINUX7111ipaddr=192.168.40.63netmask=255.255.255.0gatewayip=192.168.3.1serverip=192.168.40.19kernel_base_spark=0xa0080000kernel_base_enigma2=0x18000000kernel_sec=a0080000 a077ffffkernel_len=0x00700000update_kernel=protect off  a0080000 a077ffff ;erase  a0080000 a077ffff ;cp.b 0x80000000 0xa0080000  0x00700000 ;protect on  a0080000 a077ffffrootfs_base=0xa0800000rootfs_sec=a0800000 a1ffffffmenucmd=updatetftp_kernel_name_spark=mImagetftp_kernel_name_enigma2=uImagetftp_userfs_name_spark=userfsub.imgtftp_userfs_name_enigma2=e2jffs2.imgkernel_name_spark=spark/mImagekernel_name_enigma2=enigma2/uImageuserfs_name_spark=spark/userfsub.imguserfs_name_enigma2=enigma2/e2jffs2.imguserfs_base_spark=800000userfs_base_enigma2=18800000userfs_len_spark=17800000userfs_len_enigma2=7700000kernelnfspath=192.168.40.19:/opt/targetrootfs_name=UserFSrootfsnfspath=192.168.40.19:/home/d22cj/workspace/targetuboot_name=u-boot.binubootnfspath=192.168.40.19:/home/d22cj/workspace/targetbootfromnfs=nfs a4000000 $kernelnfspath/$kernel_name;bootm a4000000bootargs_nfs=console=ttyAS1,115200 nwhwconf=device:eth0,hwaddr:00:80:E1:12:40:61 stmmaceth=msglvl:0,phyaddr:1:watchdog:5000 root=/dev/nfs nfsroot=192.168.40.19:/opt/target,nfsvers=2,rsize=4096,wsize=8192,tcp rw ip=192.168.40.61:192.168.40.19:192.168.3.1:255.255.0.0:LINUX7111:eth0:off bigphysarea=4000bootargs_flash=console=ttyAS1,115200 rw ramdisk_size=6144 init=/linuxrc root=/dev/ram0 nwhwconf=device:eth0,hwaddr:00:80:E1:12:40:69 ip=192.168.0.69:192.168.3.119:192.168.3.1:255.255.0.0:lh:eth0:off stmmaceth=msglvl:0,phyaddr:1,watchdog:5000 bigphysarea=4000bootargs_spark=console=ttyAS1,115200 rw ramdisk_size=6144 init=/linuxrc root=/dev/ram0 nwhwconf=device:eth0,hwaddr:00:80:E1:12:40:69 ip=192.168.0.69:192.168.3.119:192.168.3.1:255.255.0.0:lh:eth0:off stmmaceth=msglvl:0,phyaddr:1,watchdog:5000 bigphysarea=4000magic_version=1.7filesize=203CA88fuseburned=truebootargs_enigma2=console=ttyAS0,115200 root=/dev/mtdblock6 rootfstype=jffs2 rw init=/bin/devinit coprocessor_mem=4m@0x40000000,4m@0x40400000 printk=1 nwhwconf=device:eth0,hwaddr:00:80:E1:12:40:69 rw ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:LINUX7111:eth0:off bigphysarea=6000 stmmaceth=msglvl:0,phyaddr:2,watchdog:5000bootargs=console=ttyAS0,115200 rw ramdisk_size=6144 init=/linuxrc root=/dev/ram0 nwhwconf=device:eth0,hwaddr:00:80:E1:12:40:69 ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:lh:eth0:off stmmaceth=msglvl:0,phyaddr:1,watchdog:5000 bigphysarea=4000bootcmd=bootm 0xa0080000boot_system=sparkuserfs_base=800000userfs_len=17800000kernel_base=0xa0080000kernel_name=spark/mImageuserfs_name=spark/userfsub.imgtftp_kernel_name=mImagetftp_userfs_name=userfsub.imgstdin=serialstdout=serialstderr=serial
Environment size: 3218/131068 bytesMB618>

Eigentlich solltest du nur den Befehl

nand bad

eingeben und nicht noch zusätzlich danach den Befehl save, ist aber kein Problem:

Code:

MB618> nand bad
Device 0 bad blocks:MB618> save  
...
Environment size: 3218/131068 bytesMB618>

Dass vor dem u-boot Prompt MB618> der Zeilenumbruch fehlt, liegt wohl an deinem Terminal-Programm (welches verwendest du?) oder am Kopieren der Meldungen in den Post hier.

Wenn nach dem Befehl

Code:

MB618>nand bad

nur die Meldung

Code:

Device 0 bad blocks:
MB618>

im Terminal-Programm angezeigt wird und sonst gar nichts, hat der NAND-Chip gar keine defekten Blöcke oder die Tabelle für vom Chip-Hersteller als defekt markierte Blöcke ist vollkommen gelöscht worden (wie auch immer, weiß ich nicht).

Mit dem u-boot Befehl nand scrub (nur einfach mit diesem diesem Befehl und kein anderer Befehl danach) wird der NAND Flash-Chip für die Kernel-/Firmware-Images vollkommen gelöscht. Die dem Befehl folgenden Terminal-Ausgaben hier posten.

Um Veränderungen der Bad-Block-Table erkennen zu können, kann/muss/sollte man als nächsten u-boot Befehl wieder den nand bad Befehl eingeben und die Meldungen hier auch wieder posten.

Wenn vor dem Löschen der NAND-Chip Bad-Blocks gehabt hätte müssten zumindest die vom Chip-Hersteller als defekt markierten Blöcke (die mit 00 Bytes) nach dem Löschen entweder noch in der Bad-Block-Table vorhanden sein (war in dem einen Fall, den ich kenne, so) oder man müsste diese Blöcke selber mit dem u-boot Befehl nand markbad versuchen als defekt zu markieren (ging in dem mir bekannten Fall aus irgendwelchen Gründen aber nicht, warum auch immer). Da der Chip bei dir eh gar keine Bad-Block-Table (mehr) zu haben scheint, ist das für dich so erstmal ohne Bedeutung.

Danke Rimini.also mit nand bad,nand scrub,nand markbad befehlen,am resi zeigt jetzt nur NULL,mit retungs Image 1.2.65,egal doch welche Image ich drauf habe?Ich habe es auch mit der Image von 1.2.52 probiert und ist das gleiche.Ich habe dir noch nicht gesagt das mit Image2 ,egal welche ich nehme, noch geht aber schlecht,nach Paar Tagen kommnt es zu störungen,kein Bild oder stendig am rückeln,nur der spark zeigt IDENT Error UNITIATE.WAs bedeutet das-MB618> nand markbadblock 0x00000000 NOT marked as bad! ERROR -5,kann das der Fehler sein?Und was kann ich noch machen?Zur zeit zeigt NULL,und Image2 geht auch nicht.Per Usb.oder mit Hyper Terminal kann ich noch alles Fläschen.Ich habe die version von Hyperterminal 6.3.und mit PuTTY geht auch,aber ich habe es noch nich rausgefunden wie ich den log von PuTTY ablesen kann.

Code:

MB618> nand bad

Device 0 bad blocks:
MB618> nand scrub


NAND scrub: device 0 whole chip
Erasing at 0x1ffe0000 -- 100% complete.
OK
MB618> nand bad


Device 0 bad blocks:
MB618> nand markbad
block 0x00000000 NOT marked as bad! ERROR -5
MB618>

mit nand bad und nand markbad

Code:

MB618> nand bad

Device 0 bad blocks:
MB618> nand markbad
block 0x00000000 NOT marked as bad! ERROR -5
MB618> nand markbad
block 0x00000000 successfully marked as bad
MB618> nand bad


Device 0 bad blocks:
  00000000
MB618>

mit print

Code:

Retungs Imade 1.2.65.mit print

Environment size: 3274/131068 bytes
MB618> print
bootdelay=3
monitor_sec=0xa0000000    0xa007ffff
ethaddr=00:80:E1:12:06:38
Exit=menu
spark(up=key)
enigma2(down=key)
RS232=Upgrade u-boot(left key)
Force=into factory mode(right key)
nand=bad
baudrate=115200
board=mb618
monitor_base=0xA0000000
monitor_len=0x00080000
load_addr=0x80000000
unprot=protect off $monitor_sec
update=protect off $monitor_sec;erase $monitor_sec;cp.b $load_addr $monitor_base
 $monitor_len;protect on $monitor_sec
HOSTNAME=LINUX7111
kernel_base_spark=0xa0080000
kernel_base_enigma2=0x18000000
kernel_sec=a0080000 a077ffff
kernel_len=0x00700000
update_kernel=protect off  a0080000 a077ffff ;erase  a0080000 a077ffff ;cp.b 0x8
0000000 0xa0080000  0x00700000 ;protect on  a0080000 a077ffff
rootfs_base=0xa0800000
rootfs_sec=a0800000 a1ffffff
menucmd=update
tftp_kernel_name_spark=mImage
tftp_kernel_name_enigma2=uImage
tftp_userfs_name_spark=userfsub.img
tftp_userfs_name_enigma2=e2jffs2.img
kernel_name_spark=spark/mImage
kernel_name_enigma2=enigma2/uImage
userfs_name_spark=spark/userfsub.img
userfs_name_enigma2=enigma2/e2jffs2.img
userfs_base_spark=800000
userfs_base_enigma2=18800000
userfs_len_spark=17800000
userfs_len_enigma2=7700000
kernelnfspath=192.168.40.19:/opt/target
rootfs_name=UserFS
rootfsnfspath=192.168.40.19:/home/d22cj/workspace/target
uboot_name=u-boot.bin
ubootnfspath=192.168.40.19:/home/d22cj/workspace/target
bootfromnfs=nfs a4000000 $kernelnfspath/$kernel_name;bootm a4000000
bootargs_nfs=console=ttyAS1,115200 nwhwconf=device:eth0,hwaddr:00:80:E1:12:40:61
 stmmaceth=msglvl:0,phyaddr:1:watchdog:5000 root=/dev/nfs nfsroot=192.168.40.19:
/opt/target,nfsvers=2,rsize=4096,wsize=8192,tcp rw ip=192.168.40.61:192.168.40.1
9:192.168.3.1:255.255.0.0:LINUX7111:eth0:off bigphysarea=4000
bootargs_flash=console=ttyAS1,115200 rw ramdisk_size=6144 init=/linuxrc root=/de
v/ram0 nwhwconf=device:eth0,hwaddr:00:80:E1:12:40:69 ip=192.168.0.69:192.168.3.1
19:192.168.3.1:255.255.0.0:lh:eth0:off stmmaceth=msglvl:0,phyaddr:1,watchdog:500
0 bigphysarea=4000
bootargs_spark=console=ttyAS1,115200 rw ramdisk_size=6144 init=/linuxrc root=/de
v/ram0 nwhwconf=device:eth0,hwaddr:00:80:E1:12:40:69 ip=192.168.0.69:192.168.3.1
19:192.168.3.1:255.255.0.0:lh:eth0:off stmmaceth=msglvl:0,phyaddr:1,watchdog:500
0 bigphysarea=4000
magic_version=1.7
bootargs_enigma2=console=ttyAS0,115200 root=/dev/mtdblock6 rootfstype=jffs2 rw i
nit=/bin/devinit coprocessor_mem=4m@0x40000000,4m@0x40400000 printk=1 nwhwconf=d
evice:eth0,hwaddr:00:80:E1:12:40:69 rw ip=${ipaddr}:${serverip}:${gatewayip}:${n
etmask}:LINUX7111:eth0:off bigphysarea=6000 stmmaceth=msglvl:0,phyaddr:2,watchdo
g:5000
IdentID=: 09 00 08 00 00 2d ea
fileaddr=80000000
gatewayip=192.168.3.1
netmask=255.255.255.0
ipaddr=192.168.40.63
serverip=192.168.40.19
filesize=3080000
fuseburned=true
bootargs=console=ttyAS1,115200 rw ramdisk_size=6144 init=/linuxrc root=/dev/ram0
 nwhwconf=device:eth0,hwaddr:00:80:E1:12:40:69 ip=192.168.0.69:192.168.3.119:192
.168.3.1:255.255.0.0:lh:eth0:off stmmaceth=msglvl:0,phyaddr:1,watchdog:5000 bigp
hysarea=4000
kernel_base=0xa0080000
kernel_name=spark/mImage
userfs_name=spark/userfsub.img
tftp_kernel_name=mImage
tftp_userfs_name=userfsub.img
userfs_len=17800000
userfs_base=800000
boot_system=spark
bootcmd=bootm  0xa0080000
stdin=serial
stdout=serial
stderr=serial


Environment size: 3274/131068 bytes
MB618>

start spark

Code:

Start spark. nach den nand bad.Image 1.2.65

Board: STx7111-Mboard (MB618)  [32-bit mode]
info: Disregarding any EPLD




U-Boot 1.3.1 (Nov 15 2010 - 17:57:53) - stm23_0043 - YW 1.0.018 Rel


DRAM:  128 MiB
NOR:     8 MiB
NAND:  512 MiB
In:    serial
Out:   serial
Err:   serial
IdentID : 09 00 0a 00 00 3e 6b
Hit ESC to stop autoboot:  0
## Booting image at a0080000 ...
   Image Name:   Kernel-Ramdisk-Image
   Image Type:   SuperH Linux Multi-File Image (gzip compressed)
   Data Size:    5867343 Bytes =   5.6 MiB
   Load Address: 80800000
   Entry Point:  80801000
   Contents:
   Image 0:  2970211 Bytes =   2.8 MiB
   Image 1:  2897119 Bytes =   2.8 MiB
   Verifying Checksum ... OK
   Uncompressing Multi-File Image ... OK
found phy at addres = 1
stmac_phy_get_addr(): id1 = 0x7, id2 = 0xc0f1
stb_id = 90a003e6b
   Loading Ramdisk to 80d3c000, length 002c34df ... OK


Starting kernel console=ttyAS1,115200 rw ramdisk_size=6144 init=/linuxrc root=/d
ev/ram0 ip=192.168.0.69:192.168.3.119:192.168.3.1:255.255.0.0:lh:eth0:off stmmac
eth=msglvl:0,phyaddr:1,watchdog:5000 bigphysarea=4000 nwhwconf=device:eth0,hwadd
r:24:00:0A:00:3E:6B Manufacture=Spark-Project STB_ID=09:00:0A:00:00:3E:6B - 0x00
53d000 - 2897119 ...

Da vor noch am 14.03 hatte ich noch das ,aber immer auch mit Error UNITIATE,und durch meine Experementen ist alles verhendet.
log spark start von 14.03.

Code:

STx7111-Mboard (MB618) [32-bit mode]info: Disregarding any EPLD




U-Boot 1.3.1 (Oct 19 2010 - 18:08:50) - stm23_0043 - YW 1.0.017 Rel


DRAM: 128 MiB
NOR: 8 MiB
NAND: 512 MiB
In: serial
Out: serial
Err: serial
IdentID : 09 00 0a 00 00 3e 6b
Hit ESC to stop autoboot: 3
Force command mode:Select boot (current boot system : spark):
1. spark(up key)
2. enigma2(down key)
3. RS232 Upgrade u-boot(left key)
4. Force into factory mode(right key)
Input Select:
xyzModem - CRC mode, 2(SOH)/512(STX)/0(CAN) packets, 2 retries
## Total Size = 0x00080000 = 524288 Bytes
............... done
Un-Protected 15 sectors


............... done
Erased 15 sectors
Copy to Flash... ................................done
............... done
Protected 15 sectors
0
## Booting image at a0080000 ...
Image Name: Kernel-Ramdisk-Image
Image Type: SuperH Linux Multi-File Image (gzip compressed)
Data Size: 5867343 Bytes = 5.6 MiB
Load Address: 80800000
Entry Point: 80801000
Contents:
Image 0: 2970211 Bytes = 2.8 MiB
Image 1: 2897119 Bytes = 2.8 MiB
Verifying Checksum ... OK
Uncompressing Multi-File Image ... OK
found phy at addres = 1
stmac_phy_get_addr(): id1 = 0x7, id2 = 0xc0f1
stb_id = 90a003e6b
Loading Ramdisk to 80d3c000, length 002c34df ... OK


Starting kernel console=ttyAS1,115200 rw ramdisk_size=6144 init=/linuxrc root=/d
ev/ram0 ip=192.168.0.69:192.168.3.119:192.168.3.1:255.255. 0.0:lh:eth0:off stmmac
eth=msglvl:0,phyaddr:1,watchdog:5000 bigphysarea=4000 nwhwconf=device:eth0,hwadd
r00:0A:00:3E:6B Manufacture=Spark-Project STB_ID=09:00:0A:00:00:3E:6B - 0x00
53d000 - 2897119 ...


[MAIN] YWIDENT_Init error,errCode=0xff03
ASSERT!! /home/d03ljf/workspace/git_source/spark_app_ret_duo_A34/src/main/main.c
(3747)
[MAIN] init finish,errCode=0
[ YWDBASEv_GetData][ 578] error 0x1f40006
[ YWDBL_CommGetVolume][ 288] YWDBLi_CommGetByFldNoWithDefault COMM_VOLUME errTy
pe = 0X1F40006 Unknown
[ YWDBASEv_GetData][ 578] error 0x1f40006
[YWDBLi_ScGetByFieldNo][ 101] YWDBL_GetSysCfgField uFieldNo = 15[YWDBL_ScGetRes
olution][ 496] YWDBLi_ScGetByFieldNo SYSCFG_DEFINITE errType = 0X1F40006 Unknow
n
########################## uiCompSize[0X00AE8BCC]================
[*error*][YWCOLLECT_GetServerUrl:340]Open net_server.xml file failed!
][/QUOTE]

Wie gesagt, der u-boot Befehl nand markbad hilft dir nicht, da man als Parameter noch die als defekt zu markierende Blocknummer angeben muss. Das wären alle die Blöcke, die mit dem Befehl nand bad vor dem nand scrub Befehl ausgegeben wurden und 00 Bytes hatten, aber nach dem nand scrub Befehl folgenden nand bad Befehl nicht mehr in der Bad-Block-Tabelle angezeigt werden.

Da bei dir schon vor dem nand scrub Befehl mit dem Befehl nand bad gar keine als defekt markierten Blöcke angezeigt wurden, kann man auch nicht sagen, ob der Flash-CVhip defekte Blöcke hat und diese nach dem nand scrub Befel mit nand markbad wieder als defekt markieren kann.

Wenn du aber den nand scrub Befehl ausgefürt hast und der Befehl fehlerfrei ausführbar war, was ja wohl der Fall war:

Code:

MB618> nand scrub


NAND scrub: device 0 whole chip
Erasing at 0x1ffe0000 -- 100% complete.
OK
MB618>

dann ist im NAND-Flash auch kein Kernel- und Firmware-Image mehr vorhanden. Man kann danach also nur noch den Receiver mit u-boot starten, aber u-boot kann kein Image, auch kein Spark-Image mahr finden und laden.

Wenn das u-boot zum Receiver passt (hab keinen Amiko Alien jemals gehabt), dann sollte man ein Spark Rettungs-Image, das neueste und zum Receiver-Modell passende (also für den Amiko Alien), flashen können.

Von dem Flash-Vorgang hätte ich gerne die Meldungen, die dabei im Terminal-Programm angezeigt werden. Alle Meldungen vom Start des Receivers nach dem nand scrub Befehl (Receiver ausschalten und etwas warten, um ihn dann zum Flashen des Rettungs-Images wieder einzuschalten) bis zum Ende des Flashvorganges des Rettungs-Images.

Bitte nicht mehr machen und nicht mehr posten, als ich/man braucht. Sonst ist das alles zu unübersichtlich, weil es nach dem nand scrub Befehl niemanden mehr intererssiert, was früher mal mit dem Receiver war, da ja der NAND-Chip vollkommen gelöscht wurde.

Danke,von anderen forum hab mal das gefunden-übersetz mit google-
Remake Amiko 8900 auf Super Box spark750! Chip Getauscht AT88SC0104CA, NOR geflasht Flush von Super Box spark750, vollständig gelöscht bündig auf NAND-Blöcke und blitzte von USB Spark_resc_img_1258, hat der Empfänger begonnen! Scans Kanäle und Show.
Er hat es geschaft,

die originale seite.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Ich kuk mal rein in resi,welchen Chip hat meiner.Ich gehe davon aus das es ein Clone ist.Ich habe schon die image 1.2.58 von Super Box 750 gefläscht,logo ist von der 750 box,aber immer noch Uninitiate error.

PS Leider habe ich den Chip nicht gefunden,das müste der große sein,aber er ist mit Alu küller beklebt,gib ein hinweiß wo der ist.



vadim

Zitat von papaber

vadim

Keine Link zu Fremdboards.
Außerdem geht dein Link nicht.

Gut, das Flashen funktioniert problemlos, also ist es kein Problem mit dem NAND-Chip. Was den Fehler verursacht, kann ich dann auch nicht sagen. Leider.

Ob das u-boot oder besser der gesamte Inhalt des NOR-Flash vollkommen stimmt, kann man so nicht genau sagen. Dazu müsste man den NOR-Chip über JTAG auslesen, was möglich ist, und mit dem Inhalt des NOR-Chips eines originalen Amiko-Receivers vergleichen (können). JTAG könnte ich machen, aber einen originalen Amiko-Receiver im Auslieferungszustand hab ich nicht.

Mit JTAG könnte man zumindest den gesamten NOR-Chip für den Bootloader auch komplett löschen und dann einen neuen Bootloader wieder flashen. Das geht eventuell auch mit dem u-boot, was z.Z. startbar ist, aber wenn das nicht richtig funktioniert, dann hat man den NOR-Chip vollkommen gelöscht und gar keinen Bootloader im NOR-Chip mehr. Dann müsste man per JTAG erstmal wieder einen Bootloader flashen können.

Wenn man die automatische Übersetzung irgendwie deuten sollte, dann gibt es das Problem bei der Super Box 750 und nicht bei einem Amiko-Receiver. Müsste mal jemand mit Russischkenntnissen, der auch den technischen Hintergrund halbwegs versteht, richtig ins Deutsche übersetzen, was dort alles geschrieben wurde.

Es geht wohl nur um den EEPROM-Chip AT88SC0104CA, ein 1KBit/128Byte Speicher, der Daten nicht einfach nur speichert, sondern die Daten durch Verschlüsselung geschützt werden:

The Atmel AT88SC0104CA member of the Atmel CryptoMemory® family is a high-performance secure memory providing 1-Kbit of user memory with advanced security and cryptographic features built in. The user memory is divided into four 32-byte zones, each of which may be individually set with different security access rights or effectively combined together to provide space for one to four data files. The AT88SC0104CA features an enhanced command set that allows direct communication with microcontroller hardware 2-wire interface thereby allowing for faster firmware development with reduced code space requirements.

Das ist ein kleiner, fast quadratischer Chip mit 8 Anschlüssen/Pins. Ob der Chip in der Super Box 750 oder im Amikao-Receiver verwendet wird, kann ich aus den Übersetzungen nicht genau herauslesen. Der Chip soll dann angeblich gegen einen normalen EEPROM ausgetauscht werden und man soll dann das Problem damit beheben können. Viel mehr kann ich mir aus automatischen Übersetzungen der Threads in den verschiedenen russischen Foren zu der Problematik nicht zusammenreimen und muss deshalb so auch gar nicht stimmen, sondern ganz anders gemeint sein.

Letztlich sicher eine sehr interessante Problematik, aber es ist fraglich, ob man das Problem wirklich gelöst bekommt und ob der Zeitaufwand dafür das überhaupt wert ist.