S4000 v1.08.65 has bricked my receiver

[chris217]

I installed the 1.08.65 update over 1.08.52 using a USB stick (as per a number of previous updates) and let the receiver get on with loading it. When I came back, the receiver was constantly rebooting.

The serial port output is below.

Nothing I have tried so far has recovered it. Any ideas, please?

U-Boot 1.3.1 (Feb 13 2010 - 14:11:39) - stm23-0032
---created by TDT for general purpose---

DRAM: 128 MB
Flash: 32 MB
In: serial
Out: serial
Err: serial
Init frontprocessor -..
Hit any key to stop autoboot: 0
bootmenu_timeout:2000,default:0
add entry:0 - ---flash---
add entry:1 - empty
add entry:2 - empty
add entry:3 - empty
add entry:4 - empty
add entry:5 - -S-USB1---
add entry:6 - -S-USB2---
add entry:7 - -S-USB3---
add entry:8 - -S-USB4---
add entry:9 - ---e2-flash---
entering bootmenu - default:0 - ---flash---
## Booting image at a0300000 ...
Image Name: Linux 2.6
Image Type: SH-4 Linux Kernel Image (gzip compressed)
Data Size: 1549343 Bytes = 1.5 MB
Load Address: 84601000
Entry Point: 84602000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK

Starting kernel console=ttyAS1,115200 root=/dev/mtdblock3 rootfstype=squashfs ip=192.168.1.4:192.168.1.23:192.1 68.1.1:255.255.255.0 nwhwconf=device:eth0,hwaddr:00:1e :b8:00:1b:d1 bigphysarea=4060 stmmaceth=msglvl:0,watchdog:4000, rxsize:16 loglevel=0 - 0x00000000 - 0 ...

init started: BusyBox v1.14.2 (2009-12-14 17:23:28 KST)
*

Board: STb7200-HDBOX [29-bit mode]

[jacksback]

Have you tried the AAF recovery tool?

[ColdAsICE]

You seem to have a boot loader/firmware clash.
Looking at your print out it seems you are using U-boot so it would be wise to either load the older firmware back in using either AAF recovery or porter(found here).
Hopefully this will un-brick your machine.
Once recovered you will have to choose which loader/firmware you actually want to use.
These sort of clashes can happen when using unofficial loaders with new official firmware releases as no pre-release testing is done with that configuration.

[chris217]

You seem to have a boot loader/firmware clash.
Looking at your print out it seems you are using U-boot so it would be wise to either load the older firmware back in using either AAF recovery or porter(found here).


Please excuse my ignorance, but what is "porter"?

Thanks.

[ManikM]

yer ive never heard of that either

[darrellr]

I have UBoot 1.3.1 installed on both boxes and have successfully upgraded both to .65

[ManikM]

me too. (on one box)

might have been a corrupt file \ dodgy USB stick.

[ColdAsICE]

Porter is the serial loader software. You will need a serial Null Modem lead and a computer with a real serial port(USB to serial adaptors are rubbish for this job).
Connect serial lead, run Porter on the computer and power up the S4000, wait till it has completed its transfer and says so on the front display of the S4000 and fingers crossed your S4000 lives again.
Good luck.

[ColdAsICE]

I'm sure I had posted Porter in the tools section sometime ago but Its no longer there so Ihave posted it again. If you need it you can find it here https://www.satpimps.co.uk/showthread.php?p=773895#post77389 5

[chris217]

I will borrow a laptop running W*nd*ws with a proper RS-232C port and try this out.

More in hope than expectation, I tried the program on my Linux box under Wine using a USB serial port (configured to be COM1). Unfortunately it could not find the serial port.

Is there a Linux program that will do the same job?

Thanks.

[chris217]

Porter.exe does not work. It just sits there saying "Waiting for Request. Reset SetTop Box."

I restored the original bootstrap loader using the AAF recovery tool. This did not resolve the problem. I then installed the AAF recovery image. This also just puts up the Busybox banner and then immediately reboots.

I tried Porter again and it still does exactly the same.

Then I tried running Porter with the box switched off and then switching the box on. This caused the box to flash ERR 0x10 on the display and the program to display "External error occurred" briefly. (This is condition is repeatable.)

This is getting interesting...

[jacksback]

I've only used the AAF recovery tool once to try out the Enigma image but think you need to change the device ID of your IceCrypt before using the recovery option or else it will fail upon boot. The recovery image is for the Atevio 7000 receiver so you need to identify your Icerypt as an Atevio before restoring.

Once restored, set your device ID back to IceCrypt and boot up, then choose to upgrade to the latest IceCrypt image via USB again

[ColdAsICE]

Jacksback is correct. Porter cannot restore your S4000 with the U-boot loader as the device ID of your receiver has changed which explains the Error code.
You will need to use AAF recovery.

[chris217]

The plot thickens: Installing the Atevio image FAC.Atevio.AV 7000HD PVR.v1.08.52.2010Oct25.ird, also causes the receiver to continually reboot. The recovery image provided by AAF works successfully.

Could it be that there is some dodgy flash memory in my receiver and this is in a critical place for the new images?

[chris217]

Yet another experiment: I tried installing the latest AAF Enigma 2 image into flash. This uploaded to the receiver, but then failed with an incorrect CRC 28C8CF9F. I checked the MD5 sum of the image file and this agrees with the .md5 file included in the download (a15da023ab10cd5044cf408918f970c5 ).

When I tried again, the same failure occurred, but the CRC reported was different (8AFBF4BA).

[jacksback]

Hi Chris.

Have you tried to put the original working image on, the one before you updated to the latest IceCrypt firmware?

[chris217]

I would put the old image back on if I could get the correct bootstrap loader back with the correct vendor ID.

My next step is to determine the memory map and run the U-Boot RAM test (if it is enabled in the Maxiboot loader.) The inconsistent checksums could be an indication of memory problems.

I am reluctant to reload the bootstrap loader any more than absolutely necessary because of the risk of permanently bricking the box. (I have a JTAG emulator and programmer at work, but this is for ARM processors and therefore may well not be compatible.)