JTAG-ing - Anyone able to advise?

I have a QNAP NMP-1000, it's a network media player. It's no' bad,
but for some time I've been trying to compile stuff on it to make
improvements. Particularly, as I've already succeeded in doing on my
Zyxel NSA221s, I wanted to get GetIPlayer going on it, and have
succeeded in doing everything required except compiling FFMPEG, which
eventually I successfully compiled a few months back on the NSA221s.
However, like a lot of other things, it just won't compile on the QNAP
because the quirky uClibc linux on mipsel combination seems to mean
that the available header files don't seem to reflect the reality of
the installed libraries.

After struggling with this every waking hour for about two weeks, last
night I finally blew, and began to investigate the possibility of
putting Debian or Slackware on it. So I tried mounting all the MTD
blocks to see what they contained. Blocks 5+ are visible normally, so
it was 0-4 that were of interest. Accordingly I tried giving commands
like ...

mount -t cramfs|jffs2 /dev/mtdblock[0-4] /mnt/tmp

.... none of which appeared to succeed, so I thought no more of this at
the time. However when I next rebooted it never got past the booting
message. Connecting via a serial lead gives the following ...

xosPe0 serial#fa8b2fdfde25c4f36f764f20b3e0bacd subid 0x50
xenv cs2 failed
xenv cs3 failed¦¦power supply: ok
dram0 ok (9)
zboot (1) failed

.... suggesting that somehow, though I really can't see how, I
corrupted the actual UBoot bootloader, or perhaps one of the other
blocks.

I've found the following thread about an Azbox showing similar
problems:
http://rickcaylor.websitetoolbox.com...27198?trail=15

"""
mack936:
everything i can find now says to there's 2 solutions:
1. send back to azbox for repair ( could most likely buy new receiver
for that charge )
2. Jtag the receiver and rewrite the flash and i'm not sure how one
would go about doing this.

MrChuckFL:
From what I have read it needs to be Jtagged and reloaded, But I can't
find procedure for doing this.
"""

What can people tell me about JTAG-ing? Does it require specialist
equipment, or is it possible for the home user, and if so, what would
I need to obtain? Can anyone point me to some straightforward
instructions to follow?

TIA
--
================================================== =======
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

Java Jive (for it is he) wrote:

What can people tell me about JTAG-ing?

Nothing, and I also know nothing about zboot or your hardware, but I suggest
you investigate the possibility that you can do a TFTP recovery instead.
Many embedded bootloaders offer the possibility to throw a firmware image at
the device with TFTP in a brief window after booting to recover in just such
a scenario as this.

--
http://ale.cx/ (AIM:troffasky) )
20:55:37 up 21 days, 11:11, 7 users, load average: 1.19, 0.69, 0.59
"If being trapped in a tropical swamp with Anthony Worral-Thompson and
Christine Hamilton is reality then I say, pass the mind-altering drugs"
-- Humphrey Lyttleton

Thanks, yes, I am aware of that possibility, and will try it as soon
as I have a PC free to be disconnected from the wider network, but:

:-( The output given up thread and the lack of response to keystrokes
sent from the PC suggest that the bootloader is cream-crackered.

:-( QNAP have a list of the models that can upgrade via TFTP, and
mine is not included in the list.

On Sun, 21 Sep 2014 20:58:49 +0100, alexd
wrote:

I suggest
you investigate the possibility that you can do a TFTP recovery instead.
Many embedded bootloaders offer the possibility to throw a firmware image at
the device with TFTP in a brief window after booting to recover in just such
a scenario as this.
--
================================================== =======
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

Java Jive wrote:
I have a QNAP NMP-1000, it's a network media player. It's no' bad,

Can we avoid this sort of pseudo-Scottish idiom from now on? If you're
going to remain as part of the UK I think it would be better if you
communicated in Home Counties English only.

Bill

On Mon, 22 Sep 2014 02:30:39 +0100, Bill Wright
wrote:

Java Jive wrote:
I have a QNAP NMP-1000, it's a network media player. It's no' bad,

Can we avoid this sort of pseudo-Scottish idiom from now on? If you're
going to remain as part of the UK I think it would be better if you
communicated in Home Counties English only.

Perhaps we should have a referendum to decide on the type of English we
should use.

--
Peter Duncanson
(in uk.tech.digital-tv)

In uk.comp.os.linux Java Jive wrote:
What can people tell me about JTAG-ing? Does it require specialist
equipment, or is it possible for the home user, and if so, what would
I need to obtain? Can anyone point me to some straightforward
instructions to follow?

It's very specific to your particular device.

JTAG is a generic test-and-debug protocol. It's a stack, a bit like
TCP/IP+Ethernet. The standard only specifies the bottom two layers, and the
rest is vendor specific.

Hardware-wise, it's simple. An old parallel port will do (with some voltage
conversion logic), otherwise there are USB-JTAG things (that are just
parallel ports in disguise). The main thing is to find something supported
by your JTAG software, because there's no standard hardware.

Software? If you want to reflash the device, there's roughly two ways to
go. One is, use some vendor protocol to flash the innards of the SoC
(eg a microcontroller with onboard flash). This bit isn't standardised, so
you'll have to find something specific to your SoC to do it.

Alternatively, the flash is external to the SoC so you have to hijack the
SoC's pins to drive the reflash protocol to the external flash chip. Not
only is that SoC-specific and flash-specific (to some degree), it's also
board-layout specific (because you need to know the the D6 pin on the flash
is wired to SoC pin 178 which is bit 635 in the pin-setting bitstream).
However in theory such 'boundary scan' is a standardised part of the JTAG
protocol (ie you can wiggle some pins without any special manufacturer
information beyond a simple description of how the pins are ordered).

So anyway, I'd look up what software is necessary to flash your particular
thing, and then work from there. Otherwise generic JTAG software like
OpenOCD is a useful starting point, but it may be that you need to use
vendor tools (that only run on Windows, or are secret, or whatever).

Theo

Perhaps we should have a referendum to exclude children and
childishness!

On Mon, 22 Sep 2014 11:10:30 +0100, Peter Duncanson
wrote:

Perhaps we should have a referendum to decide on the type of English we
should use.
--
================================================== =======
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

Thanks Theo ...

On 22 Sep 2014 13:52:36 +0100 (BST), Theo Markettos
wrote:

In uk.comp.os.linux Java Jive wrote:
What can people tell me about JTAG-ing? Does it require specialist
equipment, or is it possible for the home user, and if so, what would
I need to obtain? Can anyone point me to some straightforward
instructions to follow?

It's very specific to your particular device.

JTAG is a generic test-and-debug protocol. It's a stack, a bit like
TCP/IP+Ethernet. The standard only specifies the bottom two layers, and the
rest is vendor specific.

Hardware-wise, it's simple. An old parallel port will do (with some voltage
conversion logic), otherwise there are USB-JTAG things (that are just
parallel ports in disguise). The main thing is to find something supported
by your JTAG software, because there's no standard hardware.

Yes, since my first post, I've had a bright light, my glasses, and a
hand-lens over the board, and, although I'm reasonably certain that it
IS a JTAG system, I can't see any connector that I can definitely
recognise as that for JTAG (6MB - to ensure preservation of original
detail):

http://www.macfh.co.uk/Temp/QNAP_NMP-1000_Board.png

There's the line of three 'jumper' pin pairs top middle with the
serial connections wires still attached. By 'jumper' I mean that
normally such pin components would take 'jumpers' of the sort that,
back in the day, would have been used to set SCSI IDs, or to clear the
CMOS settings of a motherboard. Here, however, one side of each pair
seems to be used for the serial connections. At least, following
similar arrangements for other QNAP boards that are reproduced on the
web, for example this ...

http://www.cyrius.com/debian/orion/qnap/ts-109/serial/

.... those are what I connected the lead to, and, although I couldn't
get a keystroke to register, I did manage to get the meaningful log
output reproduced above, so I think I've got that right.

There's the staggered line of four connector pairs, without pins
(bottom left in the photo). However, I suspect that is too few
connectors for JTAG ...

http://www.linux-mips.org/wiki/JTAG#JTAG_headers

There's also a line of three connectors without pins (to the left of
the serial connections) but that is definitely not enough.

So, unless someone with wider experience recognises something in the
photo that I have missed, I'm a bit stuck really ...

Software? If you want to reflash the device, there's roughly two ways to
go. One is, use some vendor protocol to flash the innards of the SoC
(eg a microcontroller with onboard flash). This bit isn't standardised, so
you'll have to find something specific to your SoC to do it.

:-( Can't see QNAP being sufficiently open to tell me how to do
that.

Alternatively, the flash is external to the SoC so you have to hijack the
SoC's pins to drive the reflash protocol to the external flash chip. Not
only is that SoC-specific and flash-specific (to some degree), it's also
board-layout specific (because you need to know the the D6 pin on the flash
is wired to SoC pin 178 which is bit 635 in the pin-setting bitstream).
However in theory such 'boundary scan' is a standardised part of the JTAG
protocol (ie you can wiggle some pins without any special manufacturer
information beyond a simple description of how the pins are ordered).

Would the photo above help settle between these two possibilities?

So anyway, I'd look up what software is necessary to flash your particular
thing, and then work from there.

I'll search the QNAP forums again, and, if necessary, ask in Support.
There's no harm in trying, but I suspect I'll draw a blank either way.

Otherwise generic JTAG software like
OpenOCD is a useful starting point, but it may be that you need to use
vendor tools (that only run on Windows, or are secret, or whatever).

Yes, I'm kind of expecting that ...

I've got a free PC now, so I'll have a go at TFTP later when I return
from my constitutional, but I'm not hopeful, either with that or,
unless someone recognises a connector pattern in the photo, with JTAG.

So, I'll give it another day or two, but I suspect this will be going
into a drawer sometime soon :-(
--
================================================== =======
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

Java Jive wrote:

I can't see any connector that I can definitely
recognise as that for JTAG

Even though JTAG only requires 2 or 5 pins (plus ground?) depending on
which version it uses, there doesn't seem to be much standard for the
the physical connector, seems to vary from 8 to 20 pins in practice, or
more likely pads on the PCB that are only populated by pins on the
prototype boards

Look about on openWRT type forums where people often hack similar kit to
add serial/usb ports and occasionally need JTAG when they've bricked
them trying ...

In uk.comp.os.linux Java Jive wrote:
Yes, since my first post, I've had a bright light, my glasses, and a
hand-lens over the board, and, although I'm reasonably certain that it
IS a JTAG system, I can't see any connector that I can definitely
recognise as that for JTAG (6MB - to ensure preservation of original
detail):

http://www.macfh.co.uk/Temp/QNAP_NMP-1000_Board.png

There's a 14-pin unfitted SMD header just above the SoC and below the
battery (marked CN8) - 14 pins is something of a telltale for JTAG.
http://www.jtagtest.com/pinouts/

I'd buzz out the connector and see if it matches one of those.

There's the staggered line of four connector pairs, without pins
(bottom left in the photo). However, I suspect that is too few
connectors for JTAG ...

http://www.linux-mips.org/wiki/JTAG#JTAG_headers

Possible, but that looks like an RJ45. Phone? RS4xx? Ethernet?
Most of those seem unlikely - missing other necessary components.

:-( Can't see QNAP being sufficiently open to tell me how to do
that.

Alternatively, the flash is external to the SoC so you have to hijack the
SoC's pins to drive the reflash protocol to the external flash chip. Not
only is that SoC-specific and flash-specific (to some degree), it's also
board-layout specific (because you need to know the the D6 pin on the flash
is wired to SoC pin 178 which is bit 635 in the pin-setting bitstream).
However in theory such 'boundary scan' is a standardised part of the JTAG
protocol (ie you can wiggle some pins without any special manufacturer
information beyond a simple description of how the pins are ordered).

Would the photo above help settle between these two possibilities?

That indicates the flash is a Spansion NOR flash, to the bottom left, can't read the
number. That means the boundary scan technique is what you need to use.

The NAS uses an SMP8635 SoC from Sigma Designs. The odds are good that it
can be made to work with public information, but the question is whether
anyone has done so. 'SMP8635 jtag flash' comes up with quite a few google
hits. This bit mostly depends on the SoC and not the device it's inside
(since there will probably be only one way to wire up the flash chip).

The other question is: if your flash is broken, can you find a known-good image to
flash onto it. 'Factory restore' images don't necessarily contain partitions
in the right format. This image is the bit that is model-specific, so
an image from another SMP8635-based device might not work (but worth a try
in extremis).

Theo

PS: did you know your NAS is actually native PATA and there's a PATA-to-SATA
bridge chip on the board?