azbox elite

JTAG on Dish Receivers.
happyhammer
Junior Member
Posts: 23
Joined: Thu Oct 21, 2010 4:11 am

Post by happyhammer »

pm sent...........................
happyhammer
Junior Member
Posts: 23
Joined: Thu Oct 21, 2010 4:11 am

Post by happyhammer »

@usbbdm thanks for looking at my problem. In summary, since we can read the IDCODE which is loaded on tap reset state , does that mean that TCK and TDO are working ok?(and maybe TMS) and its only TDI that's not wotking? If so, is this a pure hardware problem(signal not connected, wrong level) or is there a firmware issue that prevents jtag working? Just looking for some direction into what to investigate.
usbbdm
Junior Member
Posts: 8962
Joined: Mon Jul 18, 2005 9:33 pm

Post by usbbdm »

happyhammer wrote:@usbbdm thanks for looking at my problem. In summary, since we can read the IDCODE which is loaded on tap reset state , does that mean that TCK and TDO are working ok?(and maybe TMS) and its only TDI that's not wotking? If so, is this a pure hardware problem(signal not connected, wrong level) or is there a firmware issue that prevents jtag working? Just looking for some direction into what to investigate.
TMS TCK and TDO are working fine. Otherwise you cannot read IDCODE. TDI is someting not working.
happyhammer
Junior Member
Posts: 23
Joined: Thu Oct 21, 2010 4:11 am

Post by happyhammer »

usbbdm wrote:TMS TCK and TDO are working fine. Otherwise you cannot read IDCODE. TDI is someting not working.
i see from other posts you had same problem with DCH 70. Were you ever able to resolve this? ( if you can't, then its very unlikely i will be able to)
usbbdm
Junior Member
Posts: 8962
Joined: Mon Jul 18, 2005 9:33 pm

Post by usbbdm »

happyhammer wrote:i see from other posts you had same problem with DCH 70. Were you ever able to resolve this? ( if you can't, then its very unlikely i will be able to)
No. I have not tested DCH70 for a long time. Maybe some one can try to use a pull up resistor on TDI to see if it solves the issue.
When you see IMPCODE FFFFFFFE it means TDI is always high to CPU. The TDI need to pull up to be able to work properly I think.
merkin
Junior Member
Posts: 246
Joined: Thu Jun 28, 2007 8:49 pm

Post by merkin »

@happyhammer

I think I found the issue.

According to your UART log http://www.satpimps.com/showthread.php? ... dead-AZBox
...detected SMP8634 (revision ES9/RevC)
xosPe0 serial#94f9be38fc043589c09643574a...
But look at the smp8634 xos release notes
SMP8634 Release 1.13, xosMe2/Pe2:
xsdk package: N/A.
xosMe2 is backward compatible with xosMc0.
xosPe2 is backward compatible with xosPc0.
Supported chips: SMP8634 ES4, ES5, ES6, ES7 and RevA, RevB
xos release notes:
Added JTAG control support for rev > ES9 and RevC.
Fixed memory overflow issue when loading xtasks.
Known bugs:
xos might hang after a soft reset if USB or PCI transfers are active.
SHA1:
xosPe2 c6fc4646a90c03fbec16cc2f4e3207bbd621f6f6
xosMe2 8014649633acb55594c99dc536a528bce85400e2

SMP8634 Release 1.12, xosMe0/Pe0:
xsdk package: XSDK_SMP8634_xosMe0-1.tar.gz.
xosMe0 is backward compatible with xosMc0.
xosPe0 is backward compatible with xosPc0.
Support chips: SMP8634 ES4, ES5, ES6, ES7 and RevA, RevB.
xos release notes:
Fixed issue with multiple-threaded xtasks causing xos to crash.
Fixed security issue regarding zboot signature verification.
Fixed xunload issue introduced in xosMde.
known bugs:
xos might hang after a soft reset if USB or PCI transfers are active.
SHA1:
xosPe0 2460281f336b14cf2052b14d09b6c3d9ae19a777
xosMe0 f058c342562fe829d5c76a2f70e63822698a00e0
You have xosMe/Pe0 running on ES9/RevC according to UART log and JTAG support was not added for that revision until xosM2/Pe2 according to xos release notes.
happyhammer
Junior Member
Posts: 23
Joined: Thu Oct 21, 2010 4:11 am

Post by happyhammer »

@merkin. Thanks for helping.

"Added JTAG control support for rev > ES9 and RevC."

i read this for boards/chips greater than ES9, not for ES9 versions.



My premium that has a working JTAG and that is also xospe0, here;s the same two lines extracted from the premium console output.


xosPe0 serial#b6cc281dccbafcc3c1103aaae2217fe3 subid 0x50

Configured for SMP863x (revision ES6/RevA), detected SMP8634 (revision ES9/RevC).
merkin
Junior Member
Posts: 246
Joined: Thu Jun 28, 2007 8:49 pm

Post by merkin »

OK then none of this makes much sense. Do you have access to t-hack private area? Opensat sent elite models to some of them. Imagine one of them tested jtag on the elite.

Is there a SMP8634 revision higher than ES9/RevC and if so would it be noted as supported for versions 1.14 and 1.15? I have my opinions, unfortunately thats all they are. Why would they mention jtag support added for chips revisions greater than ES9/RevC and not include these newly supported revisions in the latest xos release notes? Doesnt make sense.

Have you ever determined if TDI is hardwired to Vcc 3.3v? If there is no resistance between TDI and Vcc, than it must be. But could opensat be that ignorant to waste money populating jtag header after designing circuit to hardwire TDI to Vcc?

I wonder if maybe jtag bus can be disabled via xtask just like some other buses can be disabled on smp8634. If so than this would be clever of opensat to hinder cloning.

How did this elite model become bricked?

Can you upload full UART logs for both premium and elite. And also a UART log from a working elite model that has fully booted if you have one?

Does your rs232>ttl converter work on the premium to ctrl+c to interrupt boot process?

You know the UART0 is functioning and Tx +5v and GND must be fine if you are receiving the output in putty from the elite. Maybe inspect the Rx line to see if there is no resistance to GND or +5/+3Vcc. This would explain why ctrl+c does not interrupt boot process, because YAMON doesnt recognized the ascii data being received.

Do you know if a working elite model can interrupt the boot process with ctrl+c?

Also is it true to your knowledge that elite models have different flash chips?

Is it possible to interchange premium and elite firmware? Initial guess would be No, but from your info it seems possible. Again is opensat that ignorant?

Sorry for all questions, but need info to understand situation.

It seems only option is to externally burn a new flash and resolder. Is the flash BGA?

Or if TDI is in fact hardwired to Vcc, then get creative and find a way to remove the ball of solder in between the smp8634 and the circuit board. You are lucky its on the outside edge. But if jtag is somehow disabled in xos than this will not help anyway. What is there to lose at this point?

It seems the first option is better since its more guarantee. Some resellers will even burn the flash if you provide them with the firmware prior to shipment.

Or perhaps its a good candidate for ebay and save yourself the gray hair or whats left of it.

Either way good luck. Besides my inferences its beyond me at this point.
cyberdemon79
Junior Member
Posts: 1
Joined: Sun May 27, 2012 5:50 am

Post by cyberdemon79 »

Hi there,

I'm sorry for kinda hijacking this thread but it is loosely related.
Happyhammer seems to be the only one out there with the exact
same error on his faulty azbox premium so I suppose this post
is mostly directed at him, but Ieveryone's opinion is very welcome :)

When I turn mine on it mostly gets to the xenv... line, just
before dram checking occurs, sometimes it even passes to
dram checking haven't figured out when it does, seems very
random and once it got to the zboot test (which failed).

@Happyhammer did you ever figure out how to repair the faulty premium ?
I hope it is not a hardware fault.

Thanks,
Cyberdemon
PAPAUKA
Junior Member
Posts: 105
Joined: Tue Mar 31, 2009 10:25 am

Post by PAPAUKA »

happyhammer if you like i send to you all information to flash this box via SERIAL i flash multiple azbox premium and elite with no problem with serial...
Post Reply

Who is online

Users browsing this forum: No registered users and 6 guests