Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
JTAG-ing - Anyone able to advise?
178 views
Skip to first unread message
Java Jive
Sep 21, 2014, 10:38:09 AM9/21/14
to
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/post/azbox-elite-stuck-in-booting-5927198?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
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/post/azbox-elite-stuck-in-booting-5927198?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
alexd
Sep 21, 2014, 3:58:49 PM9/21/14
to
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
> What can people tell me about JTAG-ing?
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) (UnSoEs...@ale.cx)
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
Java Jive
Sep 21, 2014, 5:15:11 PM9/21/14
to
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 <trof...@hotmail.com>
wrote:
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 <trof...@hotmail.com>
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.
--
> 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.
--
Bill Wright
Sep 21, 2014, 9:30:39 PM9/21/14
to
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
> I have a QNAP NMP-1000, it's a network media player. It's no' bad,
going to remain as part of the UK I think it would be better if you
communicated in Home Counties English only.
Bill
Peter Duncanson
Sep 22, 2014, 6:10:30 AM9/22/14
to
On Mon, 22 Sep 2014 02:30:39 +0100, Bill Wright <bi...@invalid.com>
wrote:
Perhaps we should have a referendum to decide on the type of English we
should use.
--
Peter Duncanson
(in uk.tech.digital-tv)
wrote:
should use.
--
Peter Duncanson
(in uk.tech.digital-tv)
Theo Markettos
Sep 22, 2014, 8:52:36 AM9/22/14
to
In uk.comp.os.linux Java Jive <ja...@evij.com.invalid> 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.
> 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?
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
Java Jive
Sep 22, 2014, 9:05:36 AM9/22/14
to
Perhaps we should have a referendum to exclude children and
childishness!
On Mon, 22 Sep 2014 11:10:30 +0100, Peter Duncanson
<ma...@peterduncanson.net> wrote:
>
> Perhaps we should have a referendum to decide on the type of English we
> should use.
--
childishness!
On Mon, 22 Sep 2014 11:10:30 +0100, Peter Duncanson
<ma...@peterduncanson.net> wrote:
>
> Perhaps we should have a referendum to decide on the type of English we
> should use.
--
Java Jive
Sep 22, 2014, 10:35:11 AM9/22/14
to
Thanks Theo ...
On 22 Sep 2014 13:52:36 +0100 (BST), Theo Markettos
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 :-(
On 22 Sep 2014 13:52:36 +0100 (BST), Theo Markettos
<theom...@chiark.greenend.org.uk> wrote:
> In uk.comp.os.linux Java Jive <ja...@evij.com.invalid> 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
> In uk.comp.os.linux Java Jive <ja...@evij.com.invalid> 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.
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.
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).
> So anyway, I'd look up what software is necessary to flash your particular
> thing, and then work from there.
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).
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 :-(
Andy Burns
Sep 22, 2014, 11:15:40 AM9/22/14
to
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
> I can't see any connector that I can definitely
> recognise as that for JTAG
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 ...
Theo Markettos
Sep 22, 2014, 2:52:11 PM9/22/14
to
In uk.comp.os.linux Java Jive <ja...@evij.com.invalid> 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
> 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
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
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?
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?
Andy Furniss
Sep 22, 2014, 3:47:44 PM9/22/14
to
Java Jive wrote:
> 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.
Have you tried USB -
> 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.
http://www.qnap.com/useng/index.php?sn=892&c=1108&sc=1150&n=5061
Java Jive
Sep 22, 2014, 4:35:03 PM9/22/14
to
No, but I tried the Hard Disk equivalent without success before I
realised just how broken the damned thing really is. I previously had
a look at the scripts that do the flashing, and the USB method is part
of the same script that the HD method is, and it relies on normal
booting as far as the init scripts, and this is not taking place.
On Mon, 22 Sep 2014 20:47:44 +0100, Andy Furniss <spam@spam> wrote:
>
> Have you tried USB -
>
> http://www.qnap.com/useng/index.php?sn=892&c=1108&sc=1150&n=5061
realised just how broken the damned thing really is. I previously had
a look at the scripts that do the flashing, and the USB method is part
of the same script that the HD method is, and it relies on normal
booting as far as the init scripts, and this is not taking place.
On Mon, 22 Sep 2014 20:47:44 +0100, Andy Furniss <spam@spam> wrote:
>
> Have you tried USB -
>
> http://www.qnap.com/useng/index.php?sn=892&c=1108&sc=1150&n=5061
J.B.Treadstone
Sep 23, 2014, 6:13:15 AM9/23/14
to
in their alphabe'. I' seems to be qui'e common these days.
Geo
Sep 23, 2014, 6:57:53 AM9/23/14
to
On 22 Sep 2014 19:52:11 +0100 (BST), Theo Markettos
http://www.linux-mips.org/wiki/JTAG#JTAG_headers
pins 4 and 6 are connected together ( on the top layer for some
reason) so identifying them as ground may be a quick check
The pads are probably used with pogo pins in production.
<theom...@chiark.greenend.org.uk> wrote:
>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.
>
This would certainly agree with the 14 pin layout on the link given:-
>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.
>
http://www.linux-mips.org/wiki/JTAG#JTAG_headers
pins 4 and 6 are connected together ( on the top layer for some
reason) so identifying them as ground may be a quick check
The pads are probably used with pogo pins in production.
Java Jive
Sep 23, 2014, 11:28:38 PM9/23/14
to
Thanks both ...
Before answering your points in detail, I'll just mention in answer to
others that I spent a good while trying to get both the TFTP and the
USB drive methods working last night, but to no avail. This confirms
my opinion that the bootloader itself is a gonner, so any such method
based on the assumption of it working is never going to succeed.
It seems to be JTAG or nothing ...
On Tue, 23 Sep 2014 11:57:53 +0100, Geo <nhhu...@dea.spamcon.org>
wrote:
right in between the two most common sizes available of 1.27mm
(1/20in) and 2.54mm (1/10in). Consequently, despite there being
hundreds of possible suppliers, I haven't found one which definitely
and unambiguously has what I need. Further many of the hits are for
supplying commercial quantities only.
I can also forsee problems with the soldering. I do have an Antec
with a small tip, but it struggles with modern lead-free solder, and
these days my hands are not so steady as they used to be. Still, as
the unit's otherwise dead anyway, I might as well give it a go.
>>> 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.
The ethernet is on the back of the unit, part of a shrouded block also
containing 2 USB host sockets (top left of photo). See further
discussion below. If you can't suggest what that pad arrangement is,
I'd probably better not try too hard - the only thing that I can
think of is that it may be left over from an older version of the
board, perhaps something to do with an older style of front panel:
ISTR that earlier versions had a row of LEDs along the front edge of
the mainboard rather than as here an 8-segment display on a separate
board connected by the ribbon cable that you can see, and the
unidentified connector is behind where the front panel power switch
now is.
>>> 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).
I would imagine the various upgrade images available from QNAP would
be entire and complete, and would work, if I can just get the JTAG
hardware side of things together.
To do which (I'll summarise by quoting back at you to make sure that
I've understood it correctly):
1) I need to find and buy a suitable set of header pins and
solder them on to the board.
2a) Either: I need to buy a suitable USB JTAG active connection
lead with software
For example (quite expensive) ...
http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
... or (cheap) ...
http://www.ebay.de/itm/SainSmart-USB-Blaster-Programmer-Cable-For-FPGA-CPLD-JTAG-Development-Board-/320987021787?_trksid=p2054897.l5658
Any thoughts on either of these?
2b) Or: Use the parallel port method
>> PS: did you know your NAS is actually native PATA and there's a PATA-to-SATA
>> bridge chip on the board?
No, but I'm not entirely surprised ...
According to the spec, it's supposed to be Gigabit Ethernet, but I've
never got it to connect at anything above Fast Ethernet. Looking at
the init scripts the other day, I thought that maybe I could see why,
but all this blew up before I could investigate restarting the network
at a faster speed to see if the hardware could actually support it.
Can anyone tell from the photograph whether the chips on the board are
capable of Gigabit? If so, this would definitely be something I'd
wish to pursue if and when I can get it working again.
Before answering your points in detail, I'll just mention in answer to
others that I spent a good while trying to get both the TFTP and the
USB drive methods working last night, but to no avail. This confirms
my opinion that the bootloader itself is a gonner, so any such method
based on the assumption of it working is never going to succeed.
It seems to be JTAG or nothing ...
On Tue, 23 Sep 2014 11:57:53 +0100, Geo <nhhu...@dea.spamcon.org>
wrote:
>
> On 22 Sep 2014 19:52:11 +0100 (BST), Theo Markettos
> <theom...@chiark.greenend.org.uk> wrote:
>>
> On 22 Sep 2014 19:52:11 +0100 (BST), Theo Markettos
> <theom...@chiark.greenend.org.uk> wrote:
>>
>> In uk.comp.os.linux Java Jive <ja...@evij.com.invalid> 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
>>
>>>
>>> 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.
>
> This would certainly agree with the 14 pin layout on the link given:-
> http://www.linux-mips.org/wiki/JTAG#JTAG_headers
>
> pins 4 and 6 are connected together ( on the top layer for some
> reason) so identifying them as ground may be a quick check
> The pads are probably used with pogo pins in production.
One thing that worries me is that the pitch seems to be exactly 2mm,
>> 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.
>
> This would certainly agree with the 14 pin layout on the link given:-
> http://www.linux-mips.org/wiki/JTAG#JTAG_headers
>
> pins 4 and 6 are connected together ( on the top layer for some
> reason) so identifying them as ground may be a quick check
> The pads are probably used with pogo pins in production.
right in between the two most common sizes available of 1.27mm
(1/20in) and 2.54mm (1/10in). Consequently, despite there being
hundreds of possible suppliers, I haven't found one which definitely
and unambiguously has what I need. Further many of the hits are for
supplying commercial quantities only.
I can also forsee problems with the soldering. I do have an Antec
with a small tip, but it struggles with modern lead-free solder, and
these days my hands are not so steady as they used to be. Still, as
the unit's otherwise dead anyway, I might as well give it a go.
>>> 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.
containing 2 USB host sockets (top left of photo). See further
discussion below. If you can't suggest what that pad arrangement is,
I'd probably better not try too hard - the only thing that I can
think of is that it may be left over from an older version of the
board, perhaps something to do with an older style of front panel:
ISTR that earlier versions had a row of LEDs along the front edge of
the mainboard rather than as here an 8-segment display on a separate
board connected by the ribbon cable that you can see, and the
unidentified connector is behind where the front panel power switch
now is.
>>> 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).
be entire and complete, and would work, if I can just get the JTAG
hardware side of things together.
To do which (I'll summarise by quoting back at you to make sure that
I've understood it correctly):
1) I need to find and buy a suitable set of header pins and
solder them on to the board.
2a) Either: I need to buy a suitable USB JTAG active connection
lead with software
For example (quite expensive) ...
http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
... or (cheap) ...
http://www.ebay.de/itm/SainSmart-USB-Blaster-Programmer-Cable-For-FPGA-CPLD-JTAG-Development-Board-/320987021787?_trksid=p2054897.l5658
Any thoughts on either of these?
2b) Or: Use the parallel port method
>> PS: did you know your NAS is actually native PATA and there's a PATA-to-SATA
>> bridge chip on the board?
According to the spec, it's supposed to be Gigabit Ethernet, but I've
never got it to connect at anything above Fast Ethernet. Looking at
the init scripts the other day, I thought that maybe I could see why,
but all this blew up before I could investigate restarting the network
at a faster speed to see if the hardware could actually support it.
Can anyone tell from the photograph whether the chips on the board are
capable of Gigabit? If so, this would definitely be something I'd
wish to pursue if and when I can get it working again.
Andy Burns
Sep 24, 2014, 3:52:53 AM9/24/14
to
Java Jive wrote:
> One thing that worries me is that the pitch seems to be exactly 2mm,
> right in between the two most common sizes available of 1.27mm
> (1/20in) and 2.54mm (1/10in).
They've been slowly going metric
> One thing that worries me is that the pitch seems to be exactly 2mm,
> right in between the two most common sizes available of 1.27mm
> (1/20in) and 2.54mm (1/10in).
> I would imagine the various upgrade images available from QNAP would
> be entire and complete, and would work, if I can just get the JTAG
> hardware side of things together.
because any failed update to that will result in a bricked device
(requiring JTAG repair rather than TFTP repair which may just be do-able
by the end-user)
Java Jive
Sep 24, 2014, 9:13:14 AM9/24/14
to
I should've though to include this info before. The markings on the
block shrouding are ...
RU1 - 161A9WGF
0946Sa 1000BT
... and the first thing I find ...
http://www.ude-corp.com/uploads/cust/photograph/big/080618025252.pdf
.. suggests that the hardware is indeed Gigabit capable, but what I
can't work out is whether the actual rating implemented depends on
driver circuitry external to the unit, somewhere else on the board.
On Wed, 24 Sep 2014 04:28:38 +0100, Java Jive <ja...@evij.com.invalid>
wrote:
block shrouding are ...
RU1 - 161A9WGF
0946Sa 1000BT
... and the first thing I find ...
http://www.ude-corp.com/uploads/cust/photograph/big/080618025252.pdf
.. suggests that the hardware is indeed Gigabit capable, but what I
can't work out is whether the actual rating implemented depends on
driver circuitry external to the unit, somewhere else on the board.
On Wed, 24 Sep 2014 04:28:38 +0100, Java Jive <ja...@evij.com.invalid>
wrote:
>
> According to the spec, it's supposed to be Gigabit Ethernet
> According to the spec, it's supposed to be Gigabit Ethernet
Java Jive
Sep 24, 2014, 9:26:58 AM9/24/14
to
I have to repost my replies, because Geo took out the cross-post, and
that most helpful man Theo probably won't see it in uk.tech.digital-tv
alone:
1) Thanks both ...
Before answering your points in detail, I'll just mention in answer to
others that I spent a good while trying to get both the TFTP and the
USB drive methods working last night, but to no avail. This confirms
my opinion that the bootloader itself is a gonner, so any such method
based on the assumption of it working is never going to succeed.
It seems to be JTAG or nothing ...
On Tue, 23 Sep 2014 11:57:53 +0100, Geo <nhhu...@dea.spamcon.org>
wrote:
>
> On 22 Sep 2014 19:52:11 +0100 (BST), Theo Markettos
the ethernet/USB block shrouding are ...
RU1 - 161A9WGF
0946Sa 1000BT
... and the first thing I find ...
http://www.ude-corp.com/uploads/cust/photograph/big/080618025252.pdf
... suggests that the hardware is indeed Gigabit capable, but what I
that most helpful man Theo probably won't see it in uk.tech.digital-tv
alone:
1) Thanks both ...
Before answering your points in detail, I'll just mention in answer to
others that I spent a good while trying to get both the TFTP and the
USB drive methods working last night, but to no avail. This confirms
my opinion that the bootloader itself is a gonner, so any such method
based on the assumption of it working is never going to succeed.
It seems to be JTAG or nothing ...
On Tue, 23 Sep 2014 11:57:53 +0100, Geo <nhhu...@dea.spamcon.org>
wrote:
>
> <theom...@chiark.greenend.org.uk> wrote:
>>
>> In uk.comp.os.linux Java Jive <ja...@evij.com.invalid> 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.
>
>>
>> In uk.comp.os.linux Java Jive <ja...@evij.com.invalid> 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.
>
> This would certainly agree with the 14 pin layout on the link given:-
> http://www.linux-mips.org/wiki/JTAG#JTAG_headers
>
> pins 4 and 6 are connected together ( on the top layer for some
> reason) so identifying them as ground may be a quick check
> The pads are probably used with pogo pins in production.
> http://www.linux-mips.org/wiki/JTAG#JTAG_headers
>
> pins 4 and 6 are connected together ( on the top layer for some
> reason) so identifying them as ground may be a quick check
> The pads are probably used with pogo pins in production.
One thing that worries me is that the pitch seems to be exactly 2mm,
right in between the two most common sizes available of 1.27mm
right in between the two most common sizes available of 1.27mm
(1/20in) and 2.54mm (1/10in). Consequently, despite there being
hundreds of possible suppliers, I haven't found one which definitely
and unambiguously has what I need. Further many of the hits are for
supplying commercial quantities only.
I can also forsee problems with the soldering. I do have an Antec
with a small tip, but it struggles with modern lead-free solder, and
these days my hands are not so steady as they used to be. Still, as
the unit's otherwise dead anyway, I might as well give it a go.
hundreds of possible suppliers, I haven't found one which definitely
and unambiguously has what I need. Further many of the hits are for
supplying commercial quantities only.
I can also forsee problems with the soldering. I do have an Antec
with a small tip, but it struggles with modern lead-free solder, and
these days my hands are not so steady as they used to be. Still, as
the unit's otherwise dead anyway, I might as well give it a go.
>>> 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.
>>> (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.
The ethernet is on the back of the unit, part of a shrouded block also
containing 2 USB host sockets (top left of photo). See further
discussion below. If you can't suggest what that pad arrangement is,
I'd probably better not try too hard - the only thing that I can
think of is that it may be left over from an older version of the
board, perhaps something to do with an older style of front panel:
ISTR that earlier versions had a row of LEDs along the front edge of
the mainboard rather than as here an 8-segment display on a separate
board connected by the ribbon cable that you can see, and the
unidentified connector is behind where the front panel power switch
now is.
containing 2 USB host sockets (top left of photo). See further
discussion below. If you can't suggest what that pad arrangement is,
I'd probably better not try too hard - the only thing that I can
think of is that it may be left over from an older version of the
board, perhaps something to do with an older style of front panel:
ISTR that earlier versions had a row of LEDs along the front edge of
the mainboard rather than as here an 8-segment display on a separate
board connected by the ribbon cable that you can see, and the
unidentified connector is behind where the front panel power switch
now is.
>>> 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).
>>
>> 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).
I would imagine the various upgrade images available from QNAP would
be entire and complete, and would work, if I can just get the JTAG
hardware side of things together.
be entire and complete, and would work, if I can just get the JTAG
hardware side of things together.
To do which (I'll summarise by quoting back at you to make sure that
I've understood it correctly):
1) I need to find and buy a suitable set of header pins and
solder them on to the board.
2a) Either: I need to buy a suitable USB JTAG active connection
lead with software
For example (quite expensive) ...
http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
... or (cheap) ...
http://www.ebay.de/itm/SainSmart-USB-Blaster-Programmer-Cable-For-FPGA-CPLD-JTAG-Development-Board-/320987021787?_trksid=p2054897.l5658
Any thoughts on either of these?
2b) Or: Use the parallel port method
I've understood it correctly):
1) I need to find and buy a suitable set of header pins and
solder them on to the board.
2a) Either: I need to buy a suitable USB JTAG active connection
lead with software
For example (quite expensive) ...
http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
... or (cheap) ...
http://www.ebay.de/itm/SainSmart-USB-Blaster-Programmer-Cable-For-FPGA-CPLD-JTAG-Development-Board-/320987021787?_trksid=p2054897.l5658
Any thoughts on either of these?
2b) Or: Use the parallel port method
>> PS: did you know your NAS is actually native PATA and there's a PATA-to-SATA
>> bridge chip on the board?
>> bridge chip on the board?
No, but I'm not entirely surprised ...
According to the spec, it's supposed to be Gigabit Ethernet, but I've
never got it to connect at anything above Fast Ethernet. Looking at
the init scripts the other day, I thought that maybe I could see why,
but all this blew up before I could investigate restarting the network
at a faster speed to see if the hardware could actually support it.
Can anyone tell from the photograph whether the chips on the board are
capable of Gigabit? If so, this would definitely be something I'd
wish to pursue if and when I can get it working again.
2) I should've thought to include this info before. The markings on
According to the spec, it's supposed to be Gigabit Ethernet, but I've
never got it to connect at anything above Fast Ethernet. Looking at
the init scripts the other day, I thought that maybe I could see why,
but all this blew up before I could investigate restarting the network
at a faster speed to see if the hardware could actually support it.
Can anyone tell from the photograph whether the chips on the board are
capable of Gigabit? If so, this would definitely be something I'd
wish to pursue if and when I can get it working again.
the ethernet/USB block shrouding are ...
RU1 - 161A9WGF
0946Sa 1000BT
... and the first thing I find ...
http://www.ude-corp.com/uploads/cust/photograph/big/080618025252.pdf
can't work out is whether the actual rating implemented depends on
driver circuitry external to the unit, somewhere else on the board.
driver circuitry external to the unit, somewhere else on the board.
Theo Markettos
Sep 24, 2014, 2:18:24 PM9/24/14
to
In uk.comp.os.linux Java Jive <ja...@evij.com.invalid> wrote:
> One thing that worries me is that the pitch seems to be exactly 2mm,
> right in between the two most common sizes available of 1.27mm
> (1/20in) and 2.54mm (1/10in). Consequently, despite there being
> hundreds of possible suppliers, I haven't found one which definitely
> and unambiguously has what I need. Further many of the hits are for
> supplying commercial quantities only.
It's a fairly common item, such as:
> One thing that worries me is that the pitch seems to be exactly 2mm,
> right in between the two most common sizes available of 1.27mm
> (1/20in) and 2.54mm (1/10in). Consequently, despite there being
> hundreds of possible suppliers, I haven't found one which definitely
> and unambiguously has what I need. Further many of the hits are for
> supplying commercial quantities only.
http://uk.farnell.com/samtec/tmm-107-01-g-d-sm/header-2mm-dual-smd-14way/dp/1668542
(which is way expensive for what it is, but never mind)
You can buy these on strips and cut them down to length if you need.
> I can also forsee problems with the soldering. I do have an Antec
> with a small tip, but it struggles with modern lead-free solder, and
> these days my hands are not so steady as they used to be. Still, as
> the unit's otherwise dead anyway, I might as well give it a go.
in place with a small amount of solder, then solder each of the pins.
> The ethernet is on the back of the unit, part of a shrouded block also
> containing 2 USB host sockets (top left of photo). See further
> discussion below. If you can't suggest what that pad arrangement is,
> I'd probably better not try too hard - the only thing that I can
> think of is that it may be left over from an older version of the
> board, perhaps something to do with an older style of front panel:
> ISTR that earlier versions had a row of LEDs along the front edge of
> the mainboard rather than as here an 8-segment display on a separate
> board connected by the ribbon cable that you can see, and the
> unidentified connector is behind where the front panel power switch
> now is.
> I would imagine the various upgrade images available from QNAP would
> be entire and complete, and would work, if I can just get the JTAG
> hardware side of things together.
maybe not.
> To do which (I'll summarise by quoting back at you to make sure that
> I've understood it correctly):
>
> 1) I need to find and buy a suitable set of header pins and
> solder them on to the board.
>
> 2a) Either: I need to buy a suitable USB JTAG active connection
> lead with software
> For example (quite expensive) ...
> http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
> ... or (cheap) ...
> http://www.ebay.de/itm/SainSmart-USB-Blaster-Programmer-Cable-For-FPGA-CPLD-JTAG-Development-Board-/320987021787?_trksid=p2054897.l5658
>
> Any thoughts on either of these?
tool of choice it should be fine. Likewise it looks like OpenOCD supports
the FT2232 like in the first board.
> 2b) Or: Use the parallel port method
You might do this with some resistors, but I reckon this is more hassle than
buying a USB adaptor (unless you're in a hurry and have all the bits).
The other things you need to find:
Will OpenOCD work with your SoC? Is there a boundary scan pin definition file
about?
Is there a script/code to flash the Spansion flash chip via the boundary
scan?
Can you assemble an image of what the flash should look like? This is a raw
reflash, so it knows nothing about partitions for instance.
Theo
Andy Burns
Sep 24, 2014, 2:47:33 PM9/24/14
to
Java Jive wrote:
> For example (quite expensive) ...
> http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
Looks like a handy card to have around, especially as I've mislaid my
> For example (quite expensive) ...
> http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
USB to TTL level RS232 dongle, there is a cheaper "lite" version of the
TUMPA
http://vgshop.ecrater.co.uk/p/15774876/tiao-usb-multi-protocol-adapter
Dave Farrance
Sep 24, 2014, 3:59:11 PM9/24/14
to
for one to turn up from China.
http://www.ebay.co.uk/itm/251586127898
I use one for Arduino Pro microcontroller card clones, which cost �1.36
inc P&P, which seems an impossible price. But they work fine.
http://www.ebay.co.uk/itm/131268582572
Andy Burns
Sep 24, 2014, 4:13:06 PM9/24/14
to
Dave Farrance wrote:
> Arduino Pro microcontroller card clones, which cost �1.36 inc P&P,
> http://www.ebay.co.uk/itm/131268582572
I suppose at that price, you can understand why the "row needles didn't
welding", it comes to something when a bit of soldering would break the
economics of the product, even at Chinese labour rates ...
> Arduino Pro microcontroller card clones, which cost �1.36 inc P&P,
> http://www.ebay.co.uk/itm/131268582572
I suppose at that price, you can understand why the "row needles didn't
welding", it comes to something when a bit of soldering would break the
economics of the product, even at Chinese labour rates ...
Geo
Sep 25, 2014, 5:17:19 AM9/25/14
to
On Wed, 24 Sep 2014 21:13:06 +0100, Andy Burns
<usenet....@adslpipe.co.uk> wrote:
>I suppose at that price, you can understand why the "row needles didn't
>welding", it comes to something when a bit of soldering would break the
>economics of the product, even at Chinese labour rates ...
Noticed that - think it is more to do with the packaging - instead of
<usenet....@adslpipe.co.uk> wrote:
>I suppose at that price, you can understand why the "row needles didn't
>welding", it comes to something when a bit of soldering would break the
>economics of the product, even at Chinese labour rates ...
couple of mm thickness it becomes 15-20mm with sharp spikes...
Theo Markettos
Sep 25, 2014, 8:58:14 AM9/25/14
to
assembly: sheet of boards on conveyor into pick and place machine, P&P from
reels of about a dozen components, into reflow oven, dice them up, done.
The pins would probably be hand soldered, which is an extra manual step, and
there are a lot of joints for each board.
Something like that can probably do a hundreds/thousand an hour, on a fairly
cheap and basic line. If you're lucky they might put them on a test jig,
but I wouldn't count on it...
Theo
R. Mark Clayton
Sep 25, 2014, 11:43:55 AM9/25/14
to
"Bill Wright" <bi...@invalid.com> wrote in message
news:lvnu4a$edh$3...@speranza.aioe.org...
Java Jive
Sep 25, 2014, 7:13:45 PM9/25/14
to
On 24 Sep 2014 19:18:24 +0100 (BST), Theo Markettos
Turned out minimum CC order is £20, which reminded me why I was
sceptical about them! Will have to look elsewhere, perhaps here:
http://www.topqualitytools.co.uk/header-2mm-dual-smd-14way-tmm-107-01-g-d-sm/
> Just use leaded solder. Tack two corners of the connector down to hold it
> in place with a small amount of solder, then solder each of the pins.
You make it sound so simple :-)
> > I would imagine the various upgrade images available from QNAP would
> > be entire and complete, and would work, if I can just get the JTAG
> > hardware side of things together.
>
> If it does a 'dd' into the partitions you're OK, if it untars things then
> maybe not.
Had a look at two. Could only find clear text in the last 60-70 or so
bytes, so I suspect they're tar-ed and/or encrypted. See below ...
> > For example (quite expensive) ...
> > http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
> ...
option.
> The other things you need to find:
> Will OpenOCD work with your SoC? Is there a boundary scan pin definition file
> about?
Pretty close. The OpenOCD download includes an SMP8634 definition
file, as appended, which hopefully will do. Would have expected to
find such essential data on the Sigma website, but there is barely a
mention of the SMP8635 there, actually there is more about the
SMP8634. I do hate it when manufacturers clear from their sites
essential data relating to legacy products.
> Is there a script/code to flash the Spansion flash chip via the boundary
> scan?
No progress on this yet, but have found a datasheet for it:
http://www.spansion.com/Support/Datasheets/S29GL-P_00.pdf
> Can you assemble an image of what the flash should look like? This is a raw
> reflash, so it knows nothing about partitions for instance.
If not, I could just put Debian or Slackware on it, probably to be
loaded off a USB stick, with either Open NMP or XBMC.
OpenOCD's smp8634.cfg
================
# script for Sigma Designs SMP8634 (eventually even SMP8635)
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME smp8634
}
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
set _ENDIAN little
}
if { [info exists CPUTAPID] } {
set _CPUTAPID $CPUTAPID
} else {
set _CPUTAPID 0x08630001
}
adapter_nsrst_delay 100
jtag_ntrst_delay 100
reset_config trst_and_srst separate
# jtag scan chain
# format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask,
IDCODE)
jtag newtap $_CHIPNAME cpu -irlen 5 -ircapture 0x1 -irmask 0x1
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME mips_m4k -endian $_ENDIAN -variant
<theom...@chiark.greenend.org.uk> wrote:
> In uk.comp.os.linux Java Jive <ja...@evij.com.invalid> wrote:
> >
> > One thing that worries me is that the pitch seems to be exactly 2mm,
>
> In uk.comp.os.linux Java Jive <ja...@evij.com.invalid> wrote:
> >
> > One thing that worries me is that the pitch seems to be exactly 2mm,
>
> It's a fairly common item, such as:
> http://uk.farnell.com/samtec/tmm-107-01-g-d-sm/header-2mm-dual-smd-14way/dp/1668542
> (which is way expensive for what it is, but never mind)
> You can buy these on strips and cut them down to length if you need.
Always been a bit wary of Farnell, but nevertheless tried to order.
> http://uk.farnell.com/samtec/tmm-107-01-g-d-sm/header-2mm-dual-smd-14way/dp/1668542
> (which is way expensive for what it is, but never mind)
> You can buy these on strips and cut them down to length if you need.
Turned out minimum CC order is £20, which reminded me why I was
sceptical about them! Will have to look elsewhere, perhaps here:
http://www.topqualitytools.co.uk/header-2mm-dual-smd-14way-tmm-107-01-g-d-sm/
> Just use leaded solder. Tack two corners of the connector down to hold it
> in place with a small amount of solder, then solder each of the pins.
> > I would imagine the various upgrade images available from QNAP would
> > be entire and complete, and would work, if I can just get the JTAG
> > hardware side of things together.
>
> If it does a 'dd' into the partitions you're OK, if it untars things then
> maybe not.
bytes, so I suspect they're tar-ed and/or encrypted. See below ...
> > For example (quite expensive) ...
> > http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
> ...
> Likewise it looks like OpenOCD supports
> the FT2232 like in the first board.
After some reading around, beginning to favour this more expensive
> the FT2232 like in the first board.
option.
> The other things you need to find:
> Will OpenOCD work with your SoC? Is there a boundary scan pin definition file
> about?
file, as appended, which hopefully will do. Would have expected to
find such essential data on the Sigma website, but there is barely a
mention of the SMP8635 there, actually there is more about the
SMP8634. I do hate it when manufacturers clear from their sites
essential data relating to legacy products.
> Is there a script/code to flash the Spansion flash chip via the boundary
> scan?
http://www.spansion.com/Support/Datasheets/S29GL-P_00.pdf
> Can you assemble an image of what the flash should look like? This is a raw
> reflash, so it knows nothing about partitions for instance.
loaded off a USB stick, with either Open NMP or XBMC.
OpenOCD's smp8634.cfg
================
# script for Sigma Designs SMP8634 (eventually even SMP8635)
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME smp8634
}
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
set _ENDIAN little
}
if { [info exists CPUTAPID] } {
set _CPUTAPID $CPUTAPID
} else {
set _CPUTAPID 0x08630001
}
adapter_nsrst_delay 100
jtag_ntrst_delay 100
reset_config trst_and_srst separate
# jtag scan chain
# format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask,
IDCODE)
jtag newtap $_CHIPNAME cpu -irlen 5 -ircapture 0x1 -irmask 0x1
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME mips_m4k -endian $_ENDIAN -variant
Folderol
Sep 26, 2014, 12:05:40 PM9/26/14
to
On Fri, 26 Sep 2014 00:13:45 +0100
Java Jive <ja...@evij.com.invalid> wrote:
> Always been a bit wary of Farnell, but nevertheless tried to order.
> Turned out minimum CC order is £20, which reminded me why I was
> sceptical about them! Will have to look elsewhere, perhaps here:
I think you'll find that just for free delivery. They used to do free delivery
Java Jive <ja...@evij.com.invalid> wrote:
> Always been a bit wary of Farnell, but nevertheless tried to order.
> Turned out minimum CC order is £20, which reminded me why I was
> sceptical about them! Will have to look elsewhere, perhaps here:
on all orders, but there were so many people taking the piss with 50p worth of
resistors etc. that they were actually losing money. They are now in line with
firms like RS, who have always had a £20 min for free delivery.
--
W J G
Java Jive
Sep 26, 2014, 2:45:41 PM9/26/14
to
No, it's the minimum order for a non-trade account.
On Fri, 26 Sep 2014 17:05:40 +0100, Folderol <gen...@musically.me.uk>
wrote:
On Fri, 26 Sep 2014 17:05:40 +0100, Folderol <gen...@musically.me.uk>
wrote:
>
> I think you'll find that just for free delivery.
> I think you'll find that just for free delivery.
Theo Markettos
Sep 26, 2014, 7:27:50 PM9/26/14
to
In uk.comp.os.linux Java Jive <ja...@evij.com.invalid> wrote:
> Always been a bit wary of Farnell, but nevertheless tried to order.
> Turned out minimum CC order is £20, which reminded me why I was
> sceptical about them! Will have to look elsewhere, perhaps here:
CPC are the bit of Farnell with free delivery, but they don't carry that
> Always been a bit wary of Farnell, but nevertheless tried to order.
> Turned out minimum CC order is £20, which reminded me why I was
> sceptical about them! Will have to look elsewhere, perhaps here:
part.
> http://www.topqualitytools.co.uk/header-2mm-dual-smd-14way-tmm-107-01-g-d-sm/
That's just someone who orders from Farnell and resells - postage is
excessive but it's an option. I didn't try looking elsewhere, there are
probably other places too.
> > Can you assemble an image of what the flash should look like? This is a raw
> > reflash, so it knows nothing about partitions for instance.
>
> If not, I could just put Debian or Slackware on it, probably to be
> loaded off a USB stick, with either Open NMP or XBMC.
bootloader.
> OpenOCD's smp8634.cfg
That just tells it what kind of CPU it has. You need data that says how
to wiggle each pin in the thousands-bit boundary scan chain. For example:
--BSC group 208 for unused pad
"624 (BC_4, *, internal, X)," &
"625 (BC_4, *, internal, 1)," &
"626 (BC_4, *, internal, X)," &
--BSC group 209 for I/O pin 67
"627 (BC_4, IO67, input, X)," &
"628 (BC_1, *, control, 1)," &
"629 (BC_1, IO67, output3, X, 628, 1, Z)," &
--BSC group 210 for I/O pin 66
"630 (BC_4, IO66, input, X)," &
"631 (BC_1, *, control, 1)," &
"632 (BC_1, IO66, output3, X, 631, 1, Z)," &
which is taken from this BSDL file (for a randomly selected Altera chip):
ftp://ftp.altera.com/outgoing/download/bsdl/5M1270ZT144.bsd
It's possible to use the file you have to access the CPU's debug unit and
load bare-metal code in from there, and then get that to do the reflash, but
it would have to be code that knows about how to write flash on the SMP8635
- more complex than using JTAG bounary scan to wiggle the pins.
Unless you can find someone who has done this before and described the
process, or decent data on the chip, I think you're out of luck I'm
afraid.
Theo
Andy Burns
Oct 7, 2014, 4:04:51 PM10/7/14
to
Andy Burns wrote:
> Java Jive wrote:
>
>> http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
>
> Looks like a handy card to have around, especially as I've mislaid my
> USB to TTL level RS232 dongle, there is a cheaper "lite" version of the
> TUMPA
Just to mention, I id order one of of the tumpa-lite cards, and it
arrived today, I've still got to solder on its connector pins, then I'll
have a play with JTAGing an old router ... could be the sort of card I
hardly ever use, but cheap enough to have around in case it ever saves
the day ...
> Java Jive wrote:
>
>> http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
>
> Looks like a handy card to have around, especially as I've mislaid my
> USB to TTL level RS232 dongle, there is a cheaper "lite" version of the
> TUMPA
arrived today, I've still got to solder on its connector pins, then I'll
have a play with JTAGing an old router ... could be the sort of card I
hardly ever use, but cheap enough to have around in case it ever saves
the day ...
Paul D Smith
Oct 8, 2014, 3:12:27 AM10/8/14
to
"Andy Burns" wrote in message
news:PpGdnahiNc3C2qnJ...@brightview.co.uk...
+++++++++++
If you come across a good introduction and example for what JTAGing is, what
you can do with it and how, please share. I know vaguely what it is but
have yet to get well enough into it to use it in anger and most guides are
written by people who know what they're doing, for people who know what
they're doing.
Paul DS
news:PpGdnahiNc3C2qnJ...@brightview.co.uk...
If you come across a good introduction and example for what JTAGing is, what
you can do with it and how, please share. I know vaguely what it is but
have yet to get well enough into it to use it in anger and most guides are
written by people who know what they're doing, for people who know what
they're doing.
Paul DS
Andy Botterill
Oct 8, 2014, 4:28:52 PM10/8/14
to
On 08/10/14 08:12, Paul D Smith wrote:
> +++++++++++
> If you come across a good introduction and example for what JTAGing is,
> what you can do with it and how, please share. I know vaguely what it
> is but have yet to get well enough into it to use it in anger and most
> guides are written by people who know what they're doing, for people who
> know what they're doing.
>
> Paul DS
JTAG is a low level interface to integrated circuits.
> +++++++++++
> If you come across a good introduction and example for what JTAGing is,
> what you can do with it and how, please share. I know vaguely what it
> is but have yet to get well enough into it to use it in anger and most
> guides are written by people who know what they're doing, for people who
> know what they're doing.
>
> Paul DS
It can be used for PCB testing and for low level access to ARM
processors and FPGA devices. It can probably be used for other things as
well.
There is some high level explanation
in:-http://en.wikipedia.org/wiki/Joint_Test_Action_Group#Storing_firmware
For an ARM processor you can use the CoreSight software together with
the JTAG port to debug software and even integrated circuits.
JTAG is used to download the FPGA configuration data. This data makes
the FPGA into the silicon that you have designed.
There is OpenJTAG which is free software to communicate via a JTAG port.
http://en.wikipedia.org/wiki/Open_JTAG
There is also Open ocd which is intended for debugging integrated
circuits (and other things).
http://openocd.sourceforge.net/
If the hardware that you are trying to fix contains an ARM then you
should have a look at the CoreSight documentation.
One basic instruction is IDCODE. That gives you the integrated circuits
unique identifier. From there on you know exactly what integrated
circuit you are dealing with.
You can read/write to integrated circuit registers. This can be risky
you need to know what you are doing.
You can write to firmware/flash as well.
I use this in a very low level so it will not help you much.
This is the best I can think of at the moment. Good luck. Andy
Dave Farrance
Oct 25, 2014, 1:46:23 AM10/25/14
to
Dave Farrance <DaveFa...@OMiTTHiSyahooANDTHiS.co.uk> wrote:
>Andy Burns <usenet....@adslpipe.co.uk> wrote:
>
>>Java Jive wrote:
>>
>>> For example (quite expensive) ...
>>> http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
>>
>>Looks like a handy card to have around, especially as I've mislaid my
>>USB to TTL level RS232 dongle, there is a cheaper "lite" version of the
>>TUMPA
>>
>>http://vgshop.ecrater.co.uk/p/15774876/tiao-usb-multi-protocol-adapter
>
>Mind you, USB TTL cables cost £1 if you don't mind waiting the few weeks
>for one to turn up from China.
I'm returning to this old thread to note that Scottish firm FTDI released
>Andy Burns <usenet....@adslpipe.co.uk> wrote:
>
>>Java Jive wrote:
>>
>>> For example (quite expensive) ...
>>> http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
>>
>>Looks like a handy card to have around, especially as I've mislaid my
>>USB to TTL level RS232 dongle, there is a cheaper "lite" version of the
>>TUMPA
>>
>>http://vgshop.ecrater.co.uk/p/15774876/tiao-usb-multi-protocol-adapter
>
>Mind you, USB TTL cables cost £1 if you don't mind waiting the few weeks
>for one to turn up from China.
a change through Windows Update that deliberately bricks these Chinese
USB/serial cables and adaptors. Not just so that Windows refuses to work
with them, but renders them inoperable so that they can't then be used
with Linux either:
http://tinyurl.com/k3w2ztz which links to:
http://arstechnica.com/information-technology/2014/10/windows-update-drivers-bricking-usb-serial-chips-beloved-of-hardware-hackers/
Indy Jess John
Oct 25, 2014, 2:57:05 AM10/25/14
to
On 25/10/2014 06:46, Dave Farrance wrote:
> I'm returning to this old thread to note that Scottish firm FTDI released
> a change through Windows Update that deliberately bricks these Chinese
> USB/serial cables and adaptors. Not just so that Windows refuses to work
> with them, but renders them inoperable so that they can't then be used
> with Linux either:
>
> http://tinyurl.com/k3w2ztz which links to:
>
> http://arstechnica.com/information-technology/2014/10/windows-update-drivers-bricking-usb-serial-chips-beloved-of-hardware-hackers/
>
As it is a Scottish company, surely they are committing an offence under
> I'm returning to this old thread to note that Scottish firm FTDI released
> a change through Windows Update that deliberately bricks these Chinese
> USB/serial cables and adaptors. Not just so that Windows refuses to work
> with them, but renders them inoperable so that they can't then be used
> with Linux either:
>
> http://tinyurl.com/k3w2ztz which links to:
>
> http://arstechnica.com/information-technology/2014/10/windows-update-drivers-bricking-usb-serial-chips-beloved-of-hardware-hackers/
>
the Misuse of Computers Act?
Jim
Andy Burns
Oct 25, 2014, 4:03:29 AM10/25/14
to
Dave Farrance wrote:
> I'm returning to this old thread to note that Scottish firm FTDI released
> a change through Windows Update that deliberately bricks these Chinese
> USB/serial cables and adaptors.
Yes, I heard about that (but didn't check full details yet) is it
> I'm returning to this old thread to note that Scottish firm FTDI released
> a change through Windows Update that deliberately bricks these Chinese
> USB/serial cables and adaptors.
bricking boards with fake chips, or boards with genuine chips that
"borrow" the vendor/device/subsystem IDs of genuine boards? Maybe the
latter would be impossible to tell ...
Dave Farrance
Oct 25, 2014, 4:28:20 AM10/25/14
to
Indy Jess John <jimw...@OMITblueyonder.co.uk> wrote:
>On 25/10/2014 06:46, Dave Farrance wrote:
>
>> Scottish firm FTDI released a change through Windows Update that
>> deliberately bricks these Chinese USB/serial cables and adaptors.
>> Not just so that Windows refuses to work with them, but renders
>> them inoperable so that they can't then be used with Linux either:
>> http://tinyurl.com/k3w2ztz
>
>On 25/10/2014 06:46, Dave Farrance wrote:
>
>> Scottish firm FTDI released a change through Windows Update that
>> deliberately bricks these Chinese USB/serial cables and adaptors.
>> Not just so that Windows refuses to work with them, but renders
>> them inoperable so that they can't then be used with Linux either:
>> http://tinyurl.com/k3w2ztz
>
>As it is a Scottish company, surely they are committing an offence under
>the Misuse of Computers Act?
It seems to me that they're on pretty shaky ground. Chinese fakers will
>the Misuse of Computers Act?
not only duplicate the functionality of chips but put fake manufacturer
markings on them, which is definitely not on, but such cloned chips could
potentially find their way into life-protecting equipment. And although
the USB vendor-ID that FTDI re-wrote is assigned to their company, that is
not legally protected in a way that gives them the right to remove it.
I understand that the re-writing of the VID was possible because the
Chinese clones use a programmable microcontroller to emulate the FTDI
chip. FTDI have now backed down it seems, the change has been removed
from Windows Update, and they've issued a utility which reverses the
change to the cloned chips, but they're still determined to make their
drivers incompatible with the clones.
http://www.theregister.co.uk/2014/10/24/ftdi_bricking_driver_response/
I've looked at the cables and adaptors that I use, and fortunately they've
either got very old FTDI chips, predating the influx of clones, or they've
got Silicon Labs or Prolific Technology chips instead. It does seem that
the cheapest Chinese serial adaptors and cables don't use FTDI clones.
Roderick Stewart
Oct 25, 2014, 5:17:37 AM10/25/14
to
On Sat, 25 Oct 2014 09:28:17 +0100, Dave Farrance
<DaveFa...@OMiTTHiSyahooANDTHiS.co.uk> wrote:
>>
>>> Scottish firm FTDI released a change through Windows Update that
>>> deliberately bricks these Chinese USB/serial cables and adaptors.
>>> Not just so that Windows refuses to work with them, but renders
>>> them inoperable so that they can't then be used with Linux either:
>>> http://tinyurl.com/k3w2ztz
>>
>>As it is a Scottish company, surely they are committing an offence under
>>the Misuse of Computers Act?
>
>It seems to me that they're on pretty shaky ground. Chinese fakers will
>not only duplicate the functionality of chips but put fake manufacturer
>markings on them, which is definitely not on, but such cloned chips could
>potentially find their way into life-protecting equipment. And although
>the USB vendor-ID that FTDI re-wrote is assigned to their company, that is
>not legally protected in a way that gives them the right to remove it.
>
>I understand that the re-writing of the VID was possible because the
>Chinese clones use a programmable microcontroller to emulate the FTDI
>chip. FTDI have now backed down it seems, the change has been removed
>from Windows Update, and they've issued a utility which reverses the
>change to the cloned chips, but they're still determined to make their
>drivers incompatible with the clones.
It seems they're doing more than just making their drivers
<DaveFa...@OMiTTHiSyahooANDTHiS.co.uk> wrote:
>>
>>> Scottish firm FTDI released a change through Windows Update that
>>> deliberately bricks these Chinese USB/serial cables and adaptors.
>>> Not just so that Windows refuses to work with them, but renders
>>> them inoperable so that they can't then be used with Linux either:
>>> http://tinyurl.com/k3w2ztz
>>
>>As it is a Scottish company, surely they are committing an offence under
>>the Misuse of Computers Act?
>
>It seems to me that they're on pretty shaky ground. Chinese fakers will
>not only duplicate the functionality of chips but put fake manufacturer
>markings on them, which is definitely not on, but such cloned chips could
>potentially find their way into life-protecting equipment. And although
>the USB vendor-ID that FTDI re-wrote is assigned to their company, that is
>not legally protected in a way that gives them the right to remove it.
>
>I understand that the re-writing of the VID was possible because the
>Chinese clones use a programmable microcontroller to emulate the FTDI
>chip. FTDI have now backed down it seems, the change has been removed
>from Windows Update, and they've issued a utility which reverses the
>change to the cloned chips, but they're still determined to make their
>drivers incompatible with the clones.
incompatible with the clone hardware, but effectively vandalising the
clone hardware to make it incompatible with anything. Since the clones
do appear to be actual fakes, right down to the markings, rather than
reverse-engineered equivalents, the company may have a genuine legal
grievance, but it should be pursued through proper legal process like
anything else. What they are doing is more like vigilante action, and
they may live to regret it far more than they might regret losing a
few sales to the Chinese. Your point about the cloned chips being used
in life-protecting equipment is an extremelly worrying one. If this
software war doesn't stop now, it can only be a matter of time before
somebody dies as a result of it.
Rod.
Ian Jackson
Oct 25, 2014, 11:58:31 AM10/25/14
to
In message <4tpm4ap4mu08lhnj7...@4ax.com>, Roderick
Stewart <rj...@escapetime.myzen.co.uk> writes
Only last week, UK dentists were being warned to beware of buying cloned
dental equipment, as the consequences could be very serious for their
patients. It was mentioned that 'CE' might simply mean 'China Export'.
--
Ian
Stewart <rj...@escapetime.myzen.co.uk> writes
dental equipment, as the consequences could be very serious for their
patients. It was mentioned that 'CE' might simply mean 'China Export'.
--
Ian
Martin Gregorie
Oct 25, 2014, 2:13:11 PM10/25/14
to
whatever board whose mfr saw fit to buy cheap Chinese FTDI chip clones. I
believe it only affects USB<->serial adapter chips.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Andy Burns
Oct 25, 2014, 3:01:00 PM10/25/14
to
Martin Gregorie wrote:
> Its chips 'borrowing' the IDs of genuine FTDI chips. Nothing to do with
> whatever board whose mfr saw fit to buy cheap Chinese FTDI chip clones. I
> believe it only affects USB<->serial adapter chips.
yeah, but what flavour of serial? Only RS23, or the other chips that can
> Its chips 'borrowing' the IDs of genuine FTDI chips. Nothing to do with
> whatever board whose mfr saw fit to buy cheap Chinese FTDI chip clones. I
> believe it only affects USB<->serial adapter chips.
do I2C/JTAG/GOIP as well?
I've got a couple of USB->RS232-9pin cables (genuine direct from FTDI)
and one USB->TTL-level with flying leads which is likely (based on
price) to be fake, dunno where it is at moment though.
Also have the TUMPA-lite as mentioned up-thread which has an FT232H, it
is printed rather than laser etched, which I understand is a sign of
being fake, but I don't know if the legit drivers have that chip in its
sights ...
Martin Gregorie
Oct 25, 2014, 6:19:51 PM10/25/14
to
On Sat, 25 Oct 2014 20:00:57 +0100, Andy Burns wrote:
> yeah, but what flavour of serial? Only RS23, or the other chips that can
> do I2C/JTAG/GOIP as well?
>
Dunno. The stuff I saw was talking about el cheapo USB-serial adapters,
> yeah, but what flavour of serial? Only RS23, or the other chips that can
> do I2C/JTAG/GOIP as well?
>
which I assumed would be RS232. A quick scan of Ebuyer's web site shows
that their USB-serial adapters are all RS232 apart from a few RS422/485
devices. I didn't see any mention of I2C/JTAG/GOIP but then again I only
scanned the first 7 pages of 29 and the term 'USB' had pretty much
disapeared from their pages by then.
Andy Burns
Oct 26, 2014, 1:38:44 AM10/26/14
to
Martin Gregorie wrote:
> The stuff I saw was talking about el cheapo USB-serial adapters,
> which I assumed would be RS232. A quick scan of Ebuyer's web site shows
> that their USB-serial adapters are all RS232 apart from a few RS422/485
> devices. I didn't see any mention of I2C/JTAG/GOIP
Ooops, that was a typo for GPIO. Anyway will be interesting to see what
> The stuff I saw was talking about el cheapo USB-serial adapters,
> which I assumed would be RS232. A quick scan of Ebuyer's web site shows
> that their USB-serial adapters are all RS232 apart from a few RS422/485
> devices. I didn't see any mention of I2C/JTAG/GOIP
the next release of the driver does ...
Steve Thackery
Oct 26, 2014, 5:14:50 AM10/26/14
to
Martin Gregorie wrote:
> Dunno. The stuff I saw was talking about el cheapo USB-serial
> adapters, which I assumed would be RS232.
I'm one who actually got caught out. I ordered a USB to serial adapter
> Dunno. The stuff I saw was talking about el cheapo USB-serial
> adapters, which I assumed would be RS232.
so I could program the Arduino Pro Mini boards I'm playing with at the
moment. This one provides RS232 but at TTL levels (which, as you know,
is a very common arrangement). It arrived on Thursday.
I plugged it in and it simply refused to work. Windows saw the device,
but reported that it could not find a suitable driver.
However, Windows had correctly downloaded and intalled FTDI's most
recent driver (V2.12) automatically. After some web searching and
investigation, it turns out that the driver immediately overwrote the
USB PID in the fake chip, setting it from the (correct) 6001 to 0000.
It then silently terminated. There is no driver for a device with a
PID of 0000, so Windows (which uses the VID and PID to determine the
correct driver) was unable to load a suitable driver next time I
plugged it in.
Moving it to another PC was no use, of course, because the PID was now
0000. To all intents and purposes the device was now junk (sorry,
"bricked").
Let me be clear: I absolutely support FTDI's position on fake chips
(this one has the correct-looking FTDI markings on it), and if I'd
known the chip was fake I wouldn't have bought the adapter. However, I
feel it is ME who has been punished, not the vendor or the
manufacturer. Those punishments come later and indirectly, through
customers demanding refunds.
After two days FTDI removed the offending driver from Windows Update
(the current one, still called V2.12, doesn't overwrite the PID). But
it was too late for me and many other people. The worrying thing is
that these chips are used everywhere, and just bricking them next time
they are plugged in could have serious implications for some people.
Virtually all these chips (fake or real) are sold to manufacturers, not
end users, most of whom have no idea what chips are in their gadget and
whether they are real or not.
Speaking frankly, this has put me off using FTDI devices, because now I
can't tell whether I'll be getting a real chip or a fake until it stops
working one day. Sod that.
As it turns out, the situation is recoverable. Firstly, by following
this procedure you can force the FTDI driver to work with the "bricked"
device:
https://www.youtube.com/watch?v=SPdSKT6KdF8
Then you can reset the PID to the correct value like this:
https://www.youtube.com/watch?v=RZH_qGautqM
It will now work with the standard FTDI driver again, without any
manual intervention.
FTDI have said they intend to upload a new driver in due course which -
in some way not yet specified - protects them against fake devices but
without bricking the device.
--
SteveT
Java Jive
Jan 21, 2015, 10:37:51 AM1/21/15
to
On 27 Sep 2014 00:27:50 +0100 (BST), Theo Markettos
<theom...@chiark.greenend.org.uk> wrote:
>
I how have a pin header, though have yet to try soldering it onto the
NMP-1000 motherboard, interface, etc. Also ...
> > > Can you assemble an image of what the flash should look like? This is a raw
> > > reflash, so it knows nothing about partitions for instance.
> >
> > If not, I could just put Debian or Slackware on it, probably to be
> > loaded off a USB stick, with either Open NMP or XBMC.
>
> You'd still need to assemble a valid flash image, including missing
> bootloader.
QNAP have now supplied a full 64MB restore image, so I hope that now
at least this problem is solved.
> > OpenOCD's smp8634.cfg
>
> That just tells it what kind of CPU it has. You need data that says how
> to wiggle each pin in the thousands-bit boundary scan chain. For example:
>
> --BSC group 208 for unused pad
> "624 (BC_4, *, internal, X)," &
> "625 (BC_4, *, internal, 1)," &
> "626 (BC_4, *, internal, X)," &
>
> --BSC group 209 for I/O pin 67
> "627 (BC_4, IO67, input, X)," &
> "628 (BC_1, *, control, 1)," &
> "629 (BC_1, IO67, output3, X, 628, 1, Z)," &
>
> --BSC group 210 for I/O pin 66
> "630 (BC_4, IO66, input, X)," &
> "631 (BC_1, *, control, 1)," &
> "632 (BC_1, IO66, output3, X, 631, 1, Z)," &
>
> which is taken from this BSDL file (for a randomly selected Altera chip):
> ftp://ftp.altera.com/outgoing/download/bsdl/5M1270ZT144.bsd
>
> It's possible to use the file you have to access the CPU's debug unit and
> load bare-metal code in from there, and then get that to do the reflash, but
> it would have to be code that knows about how to write flash on the SMP8635
> - more complex than using JTAG bounary scan to wiggle the pins.
>
> Unless you can find someone who has done this before and described the
> process, or decent data on the chip, I think you're out of luck I'm
> afraid.
I asked QNAP for a suitable BSDL file, but all they sent me was this.
It doesn't look entirely useless, but I'm not convinced that it is
enough to do the job. What is your opinion? Is the information
contained in it actually enough?
http://www.macfh.co.uk/PrivTest/RealMagicSMP8630JTAGTutorial.pdf
--
=========================================================
UK Residents: If you feel can possibly support it
please sign the following ePetition
before closing time of 30/03/2015 23:59:
http://epetitions.direct.gov.uk/petitions/71556
<theom...@chiark.greenend.org.uk> wrote:
>
I how have a pin header, though have yet to try soldering it onto the
NMP-1000 motherboard, interface, etc. Also ...
> > > Can you assemble an image of what the flash should look like? This is a raw
> > > reflash, so it knows nothing about partitions for instance.
> >
> > If not, I could just put Debian or Slackware on it, probably to be
> > loaded off a USB stick, with either Open NMP or XBMC.
>
> You'd still need to assemble a valid flash image, including missing
> bootloader.
at least this problem is solved.
> > OpenOCD's smp8634.cfg
>
> That just tells it what kind of CPU it has. You need data that says how
> to wiggle each pin in the thousands-bit boundary scan chain. For example:
>
> --BSC group 208 for unused pad
> "624 (BC_4, *, internal, X)," &
> "625 (BC_4, *, internal, 1)," &
> "626 (BC_4, *, internal, X)," &
>
> --BSC group 209 for I/O pin 67
> "627 (BC_4, IO67, input, X)," &
> "628 (BC_1, *, control, 1)," &
> "629 (BC_1, IO67, output3, X, 628, 1, Z)," &
>
> --BSC group 210 for I/O pin 66
> "630 (BC_4, IO66, input, X)," &
> "631 (BC_1, *, control, 1)," &
> "632 (BC_1, IO66, output3, X, 631, 1, Z)," &
>
> which is taken from this BSDL file (for a randomly selected Altera chip):
> ftp://ftp.altera.com/outgoing/download/bsdl/5M1270ZT144.bsd
>
> It's possible to use the file you have to access the CPU's debug unit and
> load bare-metal code in from there, and then get that to do the reflash, but
> it would have to be code that knows about how to write flash on the SMP8635
> - more complex than using JTAG bounary scan to wiggle the pins.
>
> Unless you can find someone who has done this before and described the
> process, or decent data on the chip, I think you're out of luck I'm
> afraid.
It doesn't look entirely useless, but I'm not convinced that it is
enough to do the job. What is your opinion? Is the information
contained in it actually enough?
http://www.macfh.co.uk/PrivTest/RealMagicSMP8630JTAGTutorial.pdf
--
=========================================================
UK Residents: If you feel can possibly support it
please sign the following ePetition
before closing time of 30/03/2015 23:59:
http://epetitions.direct.gov.uk/petitions/71556
Theo Markettos
Jan 21, 2015, 11:05:01 AM1/21/15
to
In uk.comp.os.linux Java Jive <ja...@evij.com.invalid> wrote:
> I asked QNAP for a suitable BSDL file, but all they sent me was this.
> It doesn't look entirely useless, but I'm not convinced that it is
> enough to do the job. What is your opinion? Is the information
> contained in it actually enough?
>
> http://www.macfh.co.uk/PrivTest/RealMagicSMP8630JTAGTutorial.pdf
That sounds plausible. So can you get hold of the 'monice' tool, and a JTAG
> It doesn't look entirely useless, but I'm not convinced that it is
> enough to do the job. What is your opinion? Is the information
> contained in it actually enough?
>
> http://www.macfh.co.uk/PrivTest/RealMagicSMP8630JTAGTutorial.pdf
programmer that will work with it?
monice seems to use an Ethernet JTAG programmer, which sounds expensive, but
maybe there's an option to make it use a parallel port, USB or something.
Theo
Theo Markettos
Jan 21, 2015, 3:44:33 PM1/21/15
to
In uk.tech.digital-tv Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> That sounds plausible. So can you get hold of the 'monice' tool, and a JTAG
> programmer that will work with it?
Had a quick look further. It seems monice is a Mentor (ie pay $$$$$) tool,
> That sounds plausible. So can you get hold of the 'monice' tool, and a JTAG
> programmer that will work with it?
however there are other MIPS JTAG tools:
http://www.linux-mips.org/wiki/JTAG
One of those /may/ be able to flash your board, but it's unclear.
UrJTAG or OpenOCD look the most promising.
As always, YMMV.
Theo
Java Jive
Jan 23, 2015, 11:43:11 AM1/23/15
to
Thanks for your continuing help on this Theo. but I fear I'll be
asking questions still for a while ...
The first thing to report is that, now that there is some prospect of
actually fixing the unit, I went to the trouble of soldering the JTAG
jumper to the unit's board last night. As far as I can tell using a
hand-lens, the result looks alright, but whether it is actually
working has yet to be determined.
The next thing I discovered was that the lead that came with the TIAO
USB Multi-Protocol Adapter (TUMPA) ...
http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
... expected a header of larger pitch than 2mm, probably 2.54mm. I
hadn't thought that this would be a problem because the connections
are individual female sleeves, not in a block, but even so the sleeves
are too big - the first couple or so go in fine, but it gets
progressively more difficult to mount additional ones. I suppose I
need some sort of convertor, and that will involve finding one online,
ordering for a few pence with postage cost approximately 10 - 100
times the item cost, and then waiting and hoping that actually I've
managed to order the right thing :-(
Do you happen to know of such a widget?
Nevertheless, today I connected the TUMPA to my WinXP machine,
successfully installed its drivers, and then contrived to connect the
NMP-1000 by cramming the connections on as best I could, following
this tutorial (yes, I know that it's not a router) ...
http://www.tiaowiki.com/w/Debrick_Wireless_Router_Using_TUMPA_and_zJTAG
... but zJTAG failed to find the unit, despite trying with every /L1
parameter between 0 and 10, and then 149 as the documentation from
QNAP (previously linked) suggests a speed of 200Kb/s.
I guess that means one or more of:
:-( My soldering efforts weren't good enough
:-( Not all the crammed in connections were able to make
:-( I connected up wrong (see next para)
:-( zJTAG just can't recognise my type of hardware.
As far as the connecting up goes, some of the connections names in the
TUMPA manual (no longer on the TIAO site so here's my copy) ...
http://www.macfh.co.uk/PrivTest/TIAOUSBMultiProtocolAdapterUser.pdf
... have no apparent counterparts in the MIPS EJTAG connections ...
http://wiki.openwrt.org/doc/hardware/port.jtag#pin_header2
... and vice versa. To be precise ...
TUMPA only pins:
VTAR unless this corresponds to EJTAG VREF?
RST unless this corresponds to EJTAG nSRST?
RTCK
DBGRQ
DBGACK
EJTAG only pins:
VREF unless this corresponds to TUMPA VTAR?
nSRST unless this corresponds to TUMPA RST?
DINT
Do you have any knowledge to help reconcile these discrepancies?
Also ...
On 21 Jan 2015 20:44:30 +0000 (GMT), Theo Markettos
very convenient certainly, and I would very much like to get it going,
but not essential.
> however there are other MIPS JTAG tools:
> http://www.linux-mips.org/wiki/JTAG
>
> One of those /may/ be able to flash your board, but it's unclear.
> UrJTAG or OpenOCD look the most promising.
I initially went for zJTAG as described above because it might have
been a quick fix, but as it didn't come good I'll have to be more
patient and thorough. I have the source for OpenOCD, and will take a
look at this and other possibilities next.
asking questions still for a while ...
The first thing to report is that, now that there is some prospect of
actually fixing the unit, I went to the trouble of soldering the JTAG
jumper to the unit's board last night. As far as I can tell using a
hand-lens, the result looks alright, but whether it is actually
working has yet to be determined.
The next thing I discovered was that the lead that came with the TIAO
USB Multi-Protocol Adapter (TUMPA) ...
http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
... expected a header of larger pitch than 2mm, probably 2.54mm. I
hadn't thought that this would be a problem because the connections
are individual female sleeves, not in a block, but even so the sleeves
are too big - the first couple or so go in fine, but it gets
progressively more difficult to mount additional ones. I suppose I
need some sort of convertor, and that will involve finding one online,
ordering for a few pence with postage cost approximately 10 - 100
times the item cost, and then waiting and hoping that actually I've
managed to order the right thing :-(
Do you happen to know of such a widget?
Nevertheless, today I connected the TUMPA to my WinXP machine,
successfully installed its drivers, and then contrived to connect the
NMP-1000 by cramming the connections on as best I could, following
this tutorial (yes, I know that it's not a router) ...
http://www.tiaowiki.com/w/Debrick_Wireless_Router_Using_TUMPA_and_zJTAG
... but zJTAG failed to find the unit, despite trying with every /L1
parameter between 0 and 10, and then 149 as the documentation from
QNAP (previously linked) suggests a speed of 200Kb/s.
I guess that means one or more of:
:-( My soldering efforts weren't good enough
:-( Not all the crammed in connections were able to make
:-( I connected up wrong (see next para)
:-( zJTAG just can't recognise my type of hardware.
As far as the connecting up goes, some of the connections names in the
TUMPA manual (no longer on the TIAO site so here's my copy) ...
http://www.macfh.co.uk/PrivTest/TIAOUSBMultiProtocolAdapterUser.pdf
... have no apparent counterparts in the MIPS EJTAG connections ...
http://wiki.openwrt.org/doc/hardware/port.jtag#pin_header2
... and vice versa. To be precise ...
TUMPA only pins:
VTAR unless this corresponds to EJTAG VREF?
RST unless this corresponds to EJTAG nSRST?
RTCK
DBGRQ
DBGACK
EJTAG only pins:
VREF unless this corresponds to TUMPA VTAR?
nSRST unless this corresponds to TUMPA RST?
DINT
Do you have any knowledge to help reconcile these discrepancies?
Also ...
On 21 Jan 2015 20:44:30 +0000 (GMT), Theo Markettos
<theom...@chiark.greenend.org.uk> wrote:
> In uk.tech.digital-tv Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> > That sounds plausible. So can you get hold of the 'monice' tool, and a JTAG
> > programmer that will work with it?
>
> Had a quick look further. It seems monice is a Mentor (ie pay $$$$$) tool,
So that's a no-no then. The device is not that important to me -
> In uk.tech.digital-tv Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> > That sounds plausible. So can you get hold of the 'monice' tool, and a JTAG
> > programmer that will work with it?
>
> Had a quick look further. It seems monice is a Mentor (ie pay $$$$$) tool,
very convenient certainly, and I would very much like to get it going,
but not essential.
> however there are other MIPS JTAG tools:
> http://www.linux-mips.org/wiki/JTAG
>
> One of those /may/ be able to flash your board, but it's unclear.
> UrJTAG or OpenOCD look the most promising.
been a quick fix, but as it didn't come good I'll have to be more
patient and thorough. I have the source for OpenOCD, and will take a
look at this and other possibilities next.
Theo Markettos
Jan 23, 2015, 3:48:54 PM1/23/15
to
In uk.comp.os.linux Java Jive <ja...@evij.com.invalid> wrote:
> http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
>
> ... expected a header of larger pitch than 2mm, probably 2.54mm. I
> hadn't thought that this would be a problem because the connections
> are individual female sleeves, not in a block, but even so the sleeves
> are too big - the first couple or so go in fine, but it gets
> progressively more difficult to mount additional ones. I suppose I
> need some sort of convertor, and that will involve finding one online,
> ordering for a few pence with postage cost approximately 10 - 100
> times the item cost, and then waiting and hoping that actually I've
> managed to order the right thing :-(
>
> Do you happen to know of such a widget?
Look for the things that convert 2.5" PATA hard drives to 3.5" PATA. They
>
> ... expected a header of larger pitch than 2mm, probably 2.54mm. I
> hadn't thought that this would be a problem because the connections
> are individual female sleeves, not in a block, but even so the sleeves
> are too big - the first couple or so go in fine, but it gets
> progressively more difficult to mount additional ones. I suppose I
> need some sort of convertor, and that will involve finding one online,
> ordering for a few pence with postage cost approximately 10 - 100
> times the item cost, and then waiting and hoping that actually I've
> managed to order the right thing :-(
>
> Do you happen to know of such a widget?
have 2mm socket -> 2.5mm plug adaptors. Or simply solder them on.
> ... but zJTAG failed to find the unit, despite trying with every /L1
> parameter between 0 and 10, and then 149 as the documentation from
> QNAP (previously linked) suggests a speed of 200Kb/s.
>
> I guess that means one or more of:
> :-( My soldering efforts weren't good enough
> :-( Not all the crammed in connections were able to make
> :-( I connected up wrong (see next para)
> :-( zJTAG just can't recognise my type of hardware.
message. That'll indicate if those two pins are working.
> As far as the connecting up goes, some of the connections names in the
> TUMPA manual (no longer on the TIAO site so here's my copy) ...
RST=nSRST anyway. Bare minimum is TDI, TDO, TCK, TMS (and VREF depending on
the design of programmer).
Theo
Java Jive
Jan 25, 2015, 9:06:15 AM1/25/15
to
On 23 Jan 2015 20:48:50 +0000 (GMT), Theo Markettos
didn't have to vandalise, because it so happens that in line with the
JTAG connector there are no protruding components on the NMP board.
VERY useful tip, thanks yet again.
> > ... but zJTAG failed to find the unit, despite trying with every /L1
> > parameter between 0 and 10, and then 149 as the documentation from
> > QNAP (previously linked) suggests a speed of 200Kb/s.
> >
> > I guess that means one or more of:
> > :-( My soldering efforts weren't good enough
> > :-( Not all the crammed in connections were able to make
> > :-( I connected up wrong (see next para)
> > :-( zJTAG just can't recognise my type of hardware.
>
> Try shorting TDI to TDO and see if there's any difference in the error
> message. That'll indicate if those two pins are working.
A good idea in principle, but it's difficult to see how to do that in
practice because, unlike the pins on the TUMPA, the pads don't go
through to the other side of the NMP board, and it's very difficult to
trace the connections to a suitable point to place a probe - partly,
although we still have the picture of the board without the header
mounted that I linked previously ...
http://www.macfh.co.uk/Temp/QNAP_NMP-1000_Board.png
... because the header itself obscures important detail, but mainly
because everything is so damnedly small - I can only see anything
worthwhile with a x10 lens, and I'm not prepared to wait for evolution
to grow me an extra pair of hands so that I can hold the board with
one hand, the lens with another, and probes for a resistance meter
with two more ...
However I do know, because I have indeed been able to measure them
statically with a resistance meter, that on each board the GRNDs are
all connected to each other via the board itself, and therefore that
all GRND connections are good and that a GRND connection definitely
exists between the boards, and for the signal connections similarly I
know each is getting from the reverse end of its TUMPA pin (I mean
that I'm probing the base part of each pin on the other side of the
board to the connector fitting itself) to the foot of the
corresponding JTAG header pin, but there's no obvious way of being
absolutely certain that the foot of each signal JTAG header pin
actually makes electrical contact with the corresponding pad on the
board. The facts that they all look as though they ought to be, and
all the similar looking GRNDS definitely are, and that the results
obtained below vary with whether the NMP is switched on or not, all
encourage me to believe logically that all connections are good, but,
due to the difficulties outlined in the previous paragraph, I can't
think of a practical way of putting the matter beyond any doubt by
actual physical measurement.
> > As far as the connecting up goes, some of the connections names in the
> > TUMPA manual (no longer on the TIAO site so here's my copy) ...
>
> I'd guess VTAR = VREF. You don't need SRST (or TRST) but you could try
> RST=nSRST anyway. Bare minimum is TDI, TDO, TCK, TMS (and VREF depending on
> the design of programmer).
If I connect VTAR <-> VREF, an LED (red) lights on the TUMPA, and
zJTAG behaves a little differently as outlined in the next paragraph,
but otherwise I don't observe any difference. Likewise RST<->nSRST
doesn't seem to make any difference either.
Although zJTAG outputs a message "Please confirm VREF signal
connected!", its behaviour suggests that this is solely so that it can
sense whether the target board is running as it (zJATG) starts to run
- if the board is already switched on it hangs (but confusingly
without a message) waiting for you to switch the board off before it
proceeds to the prompt to switch it on. I suppose this is because it
wants to catch the board as it first boots.
I've now tried, and got not very far with:
OpenOCD v0.8.0 (Linux)
OpenOCD v0.8.0 (Windows 7)
zJTAG (Windows XP)
The results are appended below.
As they are different depending on whether the board is switched off
(ID = all 1s) and on (ID = all 0s) , I hope that means that the JTAG
header connections and the TUMPA itself are correct and working, but
I'm stumped as to how to get a more meaningful response out of the
board itself. Perhaps it's a question of knowing how to configure
OpenOCD correctly, or perhaps I need to set a jumper somewhere on the
NMP board to make it respond to JTAG, but for the moment, I'm
completely stuck.
Can anyone help with configuring OpenOCD, and/or particularly the
configuration error message from it ...
-chain-position required when creating target
... for which a search finds nothing really useful?
OpenOCD (Linux)
===============
NMP Turned off:
---------------
root@Charles-2:/home/Embedded# openocd -f
/usr/local/share/openocd/scripts/interface/ftdi/tumpa.cfg
Open On-Chip Debugger 0.8.0 (2015-01-24-20:51)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 200 kHz
none separate
in procedure 'init'
NMP Turned on:
--------------
root@Charles-2:/home/Embedded# openocd -f
/usr/local/share/openocd/scripts/interface/ftdi/tumpa.cfg
Open On-Chip Debugger 0.8.0 (2015-01-24-20:51)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 200 kHz
none separate
in procedure 'init'
root@Charles-2:/home/Embedded# openocd -f
/usr/local/share/openocd/scripts/interface/ftdi/tumpa.cfg -f
/usr/local/share/openocd/scripts/target/smp8634.cfg
Open On-Chip Debugger 0.8.0 (2015-01-24-20:51)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 200 kHz
none separate
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_push_pull
connect_deassert_srst
Warn : smp8634.cpu: nonstandard IR mask
Runtime Error: embedded:startup.tcl:20: -chain-position required when
creating target
in procedure 'script'
at file "embedded:startup.tcl", line 58
in procedure 'target' called at file
"/usr/local/share/openocd/scripts/target/smp8634.cfg", line 31
in procedure 'ocd_bouncer'
at file "embedded:startup.tcl", line 20
OpenOCD (Windows 7)
===================
NMP Turned off:
---------------
C:\Program Files\OpenOCD>"C:\Program Files\OpenOCD\bin\openocd.exe" -f
"C:\Program Files\OpenOCD\scripts\interface\ftdi\tumpa.cfg"
Open On-Chip Debugger 0.8.0 (2014-04-28-08:39)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 200 kHz
none separate
Info : clock speed 200 kHz
Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!!
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
Warn : gdb services need one or more targets defined
NMP Turned on:
--------------
C:\Program Files\OpenOCD>"C:\Program Files\OpenOCD\bin\openocd.exe" -f
"C:\Program Files\OpenOCD\scripts\interface\ftdi\tumpa.cfg"
Open On-Chip Debugger 0.8.0 (2014-04-28-08:39)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 200 kHz
none separate
Info : clock speed 200 kHz
Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!!
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: IR capture error at bit 0, saw 0x00 not 0x...3
Warn : Bypassing JTAG setup events due to errors
Warn : gdb services need one or more targets defined
C:\Program Files\OpenOCD>"C:\Program Files\OpenOCD\bin\openocd.exe" -f
"C:\Program Files\OpenOCD\scripts\interface\ftdi\tumpa.cfg" -f
"C:\Program Files\OpenOCD\scripts\target\smp8634.cfg"
Open On-Chip Debugger 0.8.0 (2014-04-28-08:39)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 200 kHz
none separate
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_push_pull
connect_dea
ssert_srst
Warn : smp8634.cpu: nonstandard IR mask
Runtime Error: embedded:startup.tcl:20: -chain-position required when
creating t
arget
in procedure 'script'
at file "embedded:startup.tcl", line 58
in procedure 'target' called at file "C:\Program
Files\OpenOCD\scripts\target\sm
p8634.cfg", line 31
in procedure 'ocd_bouncer'
at file "embedded:startup.tcl", line 20
zJTAG (Winows XP)
=================
NMP Turned off:
---------------
C:\TEMP>"C:\Program Files\ZJTAG\zjtag.exe" -probeonly /L1:149
==============================================
zJTAG EJTAG Debrick Utility v1.0
==============================================
Set I/O speed to 200 KHz
USB TAP device has been initialized. Please confirm VREF signal
connected!
Press any key to continue... ONCE target board is powered on!
Probing bus ... Done
Detected IR chain Length is 1
CPU Chip ID: 11111111111111111111111111111111 (FFFFFFFF)
*** Unknown or NO CPU Chip ID Detected ***
*** Possible Causes:
1) Router/Modem is not Connected.
2) Router/Modem is not Powered On.
3) Improper JTAG Cable.
4) Unrecognized CPU Chip ID.
NMP Turned on:
--------------
C:\TEMP>"C:\Program Files\ZJTAG\zjtag.exe" -probeonly /L1:149
==============================================
zJTAG EJTAG Debrick Utility v1.0
==============================================
Set I/O speed to 200 KHz
USB TAP device has been initialized. Please confirm VREF signal
connected!
Press any key to continue... ONCE target board is powered on!
Probing bus ... Done
Detected IR chain Length is 0
CPU Chip ID: 00000000000000000000000000000000 (00000000)
*** Unknown or NO CPU Chip ID Detected ***
*** Possible Causes:
1) Router/Modem is not Connected.
2) Router/Modem is not Powered On.
3) Improper JTAG Cable.
4) Unrecognized CPU Chip ID.
<theom...@chiark.greenend.org.uk> wrote:
>
> In uk.comp.os.linux Java Jive <ja...@evij.com.invalid> wrote:
> >
> > Do you happen to know of such a widget?
>
> Look for the things that convert 2.5" PATA hard drives to 3.5" PATA. They
> have 2mm socket -> 2.5mm plug adaptors. Or simply solder them on.
Ding! Yes, I have two of those, so even one spare, but even better I
>
> In uk.comp.os.linux Java Jive <ja...@evij.com.invalid> wrote:
> >
> > Do you happen to know of such a widget?
>
> Look for the things that convert 2.5" PATA hard drives to 3.5" PATA. They
> have 2mm socket -> 2.5mm plug adaptors. Or simply solder them on.
didn't have to vandalise, because it so happens that in line with the
JTAG connector there are no protruding components on the NMP board.
VERY useful tip, thanks yet again.
> > ... but zJTAG failed to find the unit, despite trying with every /L1
> > parameter between 0 and 10, and then 149 as the documentation from
> > QNAP (previously linked) suggests a speed of 200Kb/s.
> >
> > I guess that means one or more of:
> > :-( My soldering efforts weren't good enough
> > :-( Not all the crammed in connections were able to make
> > :-( I connected up wrong (see next para)
> > :-( zJTAG just can't recognise my type of hardware.
>
> Try shorting TDI to TDO and see if there's any difference in the error
> message. That'll indicate if those two pins are working.
practice because, unlike the pins on the TUMPA, the pads don't go
through to the other side of the NMP board, and it's very difficult to
trace the connections to a suitable point to place a probe - partly,
although we still have the picture of the board without the header
mounted that I linked previously ...
http://www.macfh.co.uk/Temp/QNAP_NMP-1000_Board.png
... because the header itself obscures important detail, but mainly
because everything is so damnedly small - I can only see anything
worthwhile with a x10 lens, and I'm not prepared to wait for evolution
to grow me an extra pair of hands so that I can hold the board with
one hand, the lens with another, and probes for a resistance meter
with two more ...
However I do know, because I have indeed been able to measure them
statically with a resistance meter, that on each board the GRNDs are
all connected to each other via the board itself, and therefore that
all GRND connections are good and that a GRND connection definitely
exists between the boards, and for the signal connections similarly I
know each is getting from the reverse end of its TUMPA pin (I mean
that I'm probing the base part of each pin on the other side of the
board to the connector fitting itself) to the foot of the
corresponding JTAG header pin, but there's no obvious way of being
absolutely certain that the foot of each signal JTAG header pin
actually makes electrical contact with the corresponding pad on the
board. The facts that they all look as though they ought to be, and
all the similar looking GRNDS definitely are, and that the results
obtained below vary with whether the NMP is switched on or not, all
encourage me to believe logically that all connections are good, but,
due to the difficulties outlined in the previous paragraph, I can't
think of a practical way of putting the matter beyond any doubt by
actual physical measurement.
> > As far as the connecting up goes, some of the connections names in the
> > TUMPA manual (no longer on the TIAO site so here's my copy) ...
>
> I'd guess VTAR = VREF. You don't need SRST (or TRST) but you could try
> RST=nSRST anyway. Bare minimum is TDI, TDO, TCK, TMS (and VREF depending on
> the design of programmer).
zJTAG behaves a little differently as outlined in the next paragraph,
but otherwise I don't observe any difference. Likewise RST<->nSRST
doesn't seem to make any difference either.
Although zJTAG outputs a message "Please confirm VREF signal
connected!", its behaviour suggests that this is solely so that it can
sense whether the target board is running as it (zJATG) starts to run
- if the board is already switched on it hangs (but confusingly
without a message) waiting for you to switch the board off before it
proceeds to the prompt to switch it on. I suppose this is because it
wants to catch the board as it first boots.
I've now tried, and got not very far with:
OpenOCD v0.8.0 (Linux)
OpenOCD v0.8.0 (Windows 7)
zJTAG (Windows XP)
The results are appended below.
As they are different depending on whether the board is switched off
(ID = all 1s) and on (ID = all 0s) , I hope that means that the JTAG
header connections and the TUMPA itself are correct and working, but
I'm stumped as to how to get a more meaningful response out of the
board itself. Perhaps it's a question of knowing how to configure
OpenOCD correctly, or perhaps I need to set a jumper somewhere on the
NMP board to make it respond to JTAG, but for the moment, I'm
completely stuck.
Can anyone help with configuring OpenOCD, and/or particularly the
configuration error message from it ...
-chain-position required when creating target
... for which a search finds nothing really useful?
OpenOCD (Linux)
===============
NMP Turned off:
---------------
root@Charles-2:/home/Embedded# openocd -f
/usr/local/share/openocd/scripts/interface/ftdi/tumpa.cfg
Open On-Chip Debugger 0.8.0 (2015-01-24-20:51)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 200 kHz
none separate
in procedure 'init'
NMP Turned on:
--------------
root@Charles-2:/home/Embedded# openocd -f
/usr/local/share/openocd/scripts/interface/ftdi/tumpa.cfg
Open On-Chip Debugger 0.8.0 (2015-01-24-20:51)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 200 kHz
none separate
in procedure 'init'
root@Charles-2:/home/Embedded# openocd -f
/usr/local/share/openocd/scripts/interface/ftdi/tumpa.cfg -f
/usr/local/share/openocd/scripts/target/smp8634.cfg
Open On-Chip Debugger 0.8.0 (2015-01-24-20:51)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 200 kHz
none separate
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_push_pull
connect_deassert_srst
Warn : smp8634.cpu: nonstandard IR mask
Runtime Error: embedded:startup.tcl:20: -chain-position required when
creating target
in procedure 'script'
at file "embedded:startup.tcl", line 58
in procedure 'target' called at file
"/usr/local/share/openocd/scripts/target/smp8634.cfg", line 31
in procedure 'ocd_bouncer'
at file "embedded:startup.tcl", line 20
OpenOCD (Windows 7)
===================
NMP Turned off:
---------------
C:\Program Files\OpenOCD>"C:\Program Files\OpenOCD\bin\openocd.exe" -f
"C:\Program Files\OpenOCD\scripts\interface\ftdi\tumpa.cfg"
Open On-Chip Debugger 0.8.0 (2014-04-28-08:39)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 200 kHz
none separate
Info : clock speed 200 kHz
Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!!
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
Warn : gdb services need one or more targets defined
NMP Turned on:
--------------
C:\Program Files\OpenOCD>"C:\Program Files\OpenOCD\bin\openocd.exe" -f
"C:\Program Files\OpenOCD\scripts\interface\ftdi\tumpa.cfg"
Open On-Chip Debugger 0.8.0 (2014-04-28-08:39)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 200 kHz
none separate
Info : clock speed 200 kHz
Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!!
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: IR capture error at bit 0, saw 0x00 not 0x...3
Warn : Bypassing JTAG setup events due to errors
Warn : gdb services need one or more targets defined
C:\Program Files\OpenOCD>"C:\Program Files\OpenOCD\bin\openocd.exe" -f
"C:\Program Files\OpenOCD\scripts\interface\ftdi\tumpa.cfg" -f
"C:\Program Files\OpenOCD\scripts\target\smp8634.cfg"
Open On-Chip Debugger 0.8.0 (2014-04-28-08:39)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 200 kHz
none separate
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_push_pull
connect_dea
ssert_srst
Warn : smp8634.cpu: nonstandard IR mask
Runtime Error: embedded:startup.tcl:20: -chain-position required when
creating t
arget
in procedure 'script'
at file "embedded:startup.tcl", line 58
in procedure 'target' called at file "C:\Program
Files\OpenOCD\scripts\target\sm
p8634.cfg", line 31
in procedure 'ocd_bouncer'
at file "embedded:startup.tcl", line 20
zJTAG (Winows XP)
=================
NMP Turned off:
---------------
C:\TEMP>"C:\Program Files\ZJTAG\zjtag.exe" -probeonly /L1:149
==============================================
zJTAG EJTAG Debrick Utility v1.0
==============================================
Set I/O speed to 200 KHz
USB TAP device has been initialized. Please confirm VREF signal
connected!
Press any key to continue... ONCE target board is powered on!
Probing bus ... Done
Detected IR chain Length is 1
CPU Chip ID: 11111111111111111111111111111111 (FFFFFFFF)
*** Unknown or NO CPU Chip ID Detected ***
*** Possible Causes:
1) Router/Modem is not Connected.
2) Router/Modem is not Powered On.
3) Improper JTAG Cable.
4) Unrecognized CPU Chip ID.
NMP Turned on:
--------------
C:\TEMP>"C:\Program Files\ZJTAG\zjtag.exe" -probeonly /L1:149
==============================================
zJTAG EJTAG Debrick Utility v1.0
==============================================
Set I/O speed to 200 KHz
USB TAP device has been initialized. Please confirm VREF signal
connected!
Press any key to continue... ONCE target board is powered on!
Probing bus ... Done
Detected IR chain Length is 0
CPU Chip ID: 00000000000000000000000000000000 (00000000)
*** Unknown or NO CPU Chip ID Detected ***
*** Possible Causes:
1) Router/Modem is not Connected.
2) Router/Modem is not Powered On.
3) Improper JTAG Cable.
4) Unrecognized CPU Chip ID.
Java Jive
Jan 25, 2015, 9:00:26 PM1/25/15
to
Actually, by means of greatly zoomed photos, and the hand lens, I've
managed to find more or less accessible test-points for all the pins,
and have thereby confirmed by actual, physical measurement that all
the connections are correctly made.
But, btw, I take it that the zJTAG tutorial I linked previously is
correct in giving the wiring as straight through ...
TDI <-> TDI
TDO <-> TDO
... and not crossed over ...
TDI <-> TDO
TDO <-> TDI
???
On Sun, 25 Jan 2015 14:06:12 +0000, Java Jive <ja...@evij.com.invalid>
wrote:
managed to find more or less accessible test-points for all the pins,
and have thereby confirmed by actual, physical measurement that all
the connections are correctly made.
But, btw, I take it that the zJTAG tutorial I linked previously is
correct in giving the wiring as straight through ...
TDI <-> TDI
TDO <-> TDO
... and not crossed over ...
TDI <-> TDO
TDO <-> TDI
???
On Sun, 25 Jan 2015 14:06:12 +0000, Java Jive <ja...@evij.com.invalid>
wrote:
>
> and for the signal connections similarly I
> know each is getting from the reverse end of its TUMPA pin (I mean
> that I'm probing the base part of each pin on the other side of the
> board to the connector fitting itself) to the foot of the
> corresponding JTAG header pin, but there's no obvious way of being
> absolutely certain that the foot of each signal JTAG header pin
> actually makes electrical contact with the corresponding pad on the
> board. The facts that they all look as though they ought to be, and
> all the similar looking GRNDS definitely are, and that the results
> obtained below vary with whether the NMP is switched on or not, all
> encourage me to believe logically that all connections are good, but,
> due to the difficulties outlined in the previous paragraph, I can't
> think of a practical way of putting the matter beyond any doubt by
> actual physical measurement.
> and for the signal connections similarly I
> know each is getting from the reverse end of its TUMPA pin (I mean
> that I'm probing the base part of each pin on the other side of the
> board to the connector fitting itself) to the foot of the
> corresponding JTAG header pin, but there's no obvious way of being
> absolutely certain that the foot of each signal JTAG header pin
> actually makes electrical contact with the corresponding pad on the
> board. The facts that they all look as though they ought to be, and
> all the similar looking GRNDS definitely are, and that the results
> obtained below vary with whether the NMP is switched on or not, all
> encourage me to believe logically that all connections are good, but,
> due to the difficulties outlined in the previous paragraph, I can't
> think of a practical way of putting the matter beyond any doubt by
> actual physical measurement.
Java Jive
Jan 25, 2015, 11:04:29 PM1/25/15
to
This is my current bet, a la AzBox requiring R309 to be shorted to
enable the JTAG. My bet for the NMP-1000 is short R209, which is in a
very similar position to R309 on the AzBox. However, to be sure I've
asked QNAP support ...
On Sun, 25 Jan 2015 14:06:12 +0000, Java Jive <ja...@evij.com.invalid>
wrote:
>
enable the JTAG. My bet for the NMP-1000 is short R209, which is in a
very similar position to R309 on the AzBox. However, to be sure I've
asked QNAP support ...
On Sun, 25 Jan 2015 14:06:12 +0000, Java Jive <ja...@evij.com.invalid>
wrote:
>
> or perhaps I need to set a jumper somewhere on the
> NMP board to make it respond to JTAG
> NMP board to make it respond to JTAG
Theo Markettos
Jan 28, 2015, 1:23:02 PM1/28/15
to
In uk.comp.os.linux Java Jive <ja...@evij.com.invalid> wrote:
> On 23 Jan 2015 20:48:50 +0000 (GMT), Theo Markettos
> <theom...@chiark.greenend.org.uk> wrote:
> >
> > Try shorting TDI to TDO and see if there's any difference in the error
> > message. That'll indicate if those two pins are working.
>
> A good idea in principle, but it's difficult to see how to do that in
> practice because, unlike the pins on the TUMPA, the pads don't go
> through to the other side of the NMP board, and it's very difficult to
> trace the connections to a suitable point to place a probe - partly,
> although we still have the picture of the board without the header
> mounted that I linked previously ...
> http://www.macfh.co.uk/Temp/QNAP_NMP-1000_Board.png
> ... because the header itself obscures important detail, but mainly
> because everything is so damnedly small - I can only see anything
> worthwhile with a x10 lens, and I'm not prepared to wait for evolution
> to grow me an extra pair of hands so that I can hold the board with
> one hand, the lens with another, and probes for a resistance meter
> with two more ...
You don't need the board connected to short the pins together, it's simply a
> On 23 Jan 2015 20:48:50 +0000 (GMT), Theo Markettos
> <theom...@chiark.greenend.org.uk> wrote:
> >
> > Try shorting TDI to TDO and see if there's any difference in the error
> > message. That'll indicate if those two pins are working.
>
> A good idea in principle, but it's difficult to see how to do that in
> practice because, unlike the pins on the TUMPA, the pads don't go
> through to the other side of the NMP board, and it's very difficult to
> trace the connections to a suitable point to place a probe - partly,
> although we still have the picture of the board without the header
> mounted that I linked previously ...
> http://www.macfh.co.uk/Temp/QNAP_NMP-1000_Board.png
> ... because the header itself obscures important detail, but mainly
> because everything is so damnedly small - I can only see anything
> worthwhile with a x10 lens, and I'm not prepared to wait for evolution
> to grow me an extra pair of hands so that I can hold the board with
> one hand, the lens with another, and probes for a resistance meter
> with two more ...
check that the JTAG cable is working (it should show 'no devices found' in
that case).
> If I connect VTAR <-> VREF, an LED (red) lights on the TUMPA, and
> zJTAG behaves a little differently as outlined in the next paragraph,
> but otherwise I don't observe any difference. Likewise RST<->nSRST
> doesn't seem to make any difference either.
> Although zJTAG outputs a message "Please confirm VREF signal
> connected!", its behaviour suggests that this is solely so that it can
> sense whether the target board is running as it (zJATG) starts to run
> - if the board is already switched on it hangs (but confusingly
> without a message) waiting for you to switch the board off before it
> proceeds to the prompt to switch it on. I suppose this is because it
> wants to catch the board as it first boots.
>
> I've now tried, and got not very far with:
> OpenOCD v0.8.0 (Linux)
> OpenOCD v0.8.0 (Windows 7)
> zJTAG (Windows XP)
>
> The results are appended below.
>
> As they are different depending on whether the board is switched off
> (ID = all 1s) and on (ID = all 0s) , I hope that means that the JTAG
> header connections and the TUMPA itself are correct and working, but
> I'm stumped as to how to get a more meaningful response out of the
> board itself. Perhaps it's a question of knowing how to configure
> OpenOCD correctly, or perhaps I need to set a jumper somewhere on the
> NMP board to make it respond to JTAG, but for the moment, I'm
> completely stuck.
voltages change at all (better a scope if you have one). You should see
TCK, TMS and TDI on the chip change when you run the programming software.
> Can anyone help with configuring OpenOCD, and/or particularly the
> configuration error message from it ...
>
> -chain-position required when creating target
>
> ... for which a search finds nothing really useful?
the next. You need to specify which device in the chain you have. However
it looks like you have either a broken chain, or a chain of zero devices (if
you short TDO to TDI). If the chip is successfully connected you'll have
one or more devices and need to select which one.
It's quite easy to get TDI and TDO mixed up - eg the programmer probably
outputs on TDI since it expects to feed a TDI input on a chip.
If it doubt try them both ways.
You should be able to read the chip ID at least, but from there it's still
an open question whether you can get any further with the open source tools.
Theo
Java Jive
Jan 31, 2015, 6:28:58 PM1/31/15
to
On 28 Jan 2015 18:22:58 +0000 (GMT), Theo Markettos
C:\TEMP>"C:\Program Files\ZJTAG\zjtag.exe" -probeonly
USB TAP device has been initialized. Please confirm VREF signal
connected!
device is on or not. OpenOCD appears to be indifferent.
> Worth probing the TDI and TDO pins with a multimeter and seeing whether the
> voltages change at all (better a scope if you have one). You should see
> TCK, TMS and TDI on the chip change when you run the programming software.
Not having got as far as running programming software yet, I tried
doing this as the ID was queried, but, having just the normal quota of
two hands, it was difficult to get keep the probes stable with one
while I ran the software with the other, and the results were
inconclusive.
> JTAG chains the devices on the board together - TDO from one goes to TDI of
> the next. You need to specify which device in the chain you have. However
> it looks like you have either a broken chain, or a chain of zero devices (if
> you short TDO to TDI). If the chip is successfully connected you'll have
> one or more devices and need to select which one.
>
> It's quite easy to get TDI and TDO mixed up - eg the programmer probably
> outputs on TDI since it expects to feed a TDI input on a chip.
> If it doubt try them both ways.
Straight through connection ...
board, all 0s if there is power, while crossed over ...
From which I conclude that in this case straight through is correct,
as that scheme is responsive to change.
> You should be able to read the chip ID at least, but from there it's still
> an open question whether you can get any further with the open source tools.
Well, I can't the read the chip ID, and, having comprehensively
checked all the connections using the meter, and having been led to
believe by its output that the TUMPA is working correctly, I'm now
reasonably certain that the reason for my failure thus far is the
following ...
> On Sun, 25 Jan 2015 14:06:12 +0000, Java Jive <ja...@evij.com.invalid>
> wrote:
> >
wrote:
>
To begin with, QNAP have gone coy on me, no reply to my request for
information about enabling the JTAG despite a follow-up reminder. So
yesterday, I tried shorting R209 and it made ... no difference. I was
gutted, I'd been so sure that it would work, but it appears JTAG is
still not enabled, and still there's no meaningful ID coming back.
However, consequently examining more closely the photos of other
boards which are on the net, for example the most documented seems to
be the Azbox ...
http://img571.imageshack.us/img571/6427/93122218.jpg
... led me to realise that anyway the tracks from R309 on the Azbox,
which lead off to the area around rows 11 and 12 of the CPU pins, were
very unlikely to go to the same pins as those from R209 on the
NMP-1000, which are further down the side of the processor and go to
the area around rows 15 and 16.
So I searched for a CPU pinout and eventually found this ...
http://hwdb.mipt.cc/SMP8634/Pinout
... which revealed that the name of pin D11, JTAG_UART#, is the only
one to mention JTAG. Therefore, I think it can be presumed safely
that one of the tracks from R309 on the Azbox PCB goes to this pin.
Consequently, I also presume that if this pin is held to one of Vss or
GND, JTAG is enabled, but if the other, disabled. PCB designers can
thus choose:
:-) Permanently enable
:-( Permanently disable
:-! Enable via jumper or soldered jump
Three questions now remain:
1) To enable JTAG, should D11 be shorted be to Vss or GND?
1) Ought a resistor be used, and if so, what value?
2) Where are the equivalent points on the NMP-1000 PCB?
1 & 2)
Of the various sites quoting this jump for the Azbox, most seem to be
auto-translations of other pages, often themselves auto-translations
of still yet others, making it difficult to work out which page(s)
were originals. Some seem to have derived from a page on a Russian
language German site www.pristavka.de, of which the original no longer
exists. Others refer to this as a possible original ...
https://translate.google.co.uk/translate?sl=ru&tl=en&hl=en&ie=UTF-8&u=http%3A%2F%2Fwww.google.co.uk%2Furl%3Fq%3Dhttp%3A%2F%2Fipbox.com.ua%2Fshowthread.php%2F5219-%2525D1%252583%2525D1%252581%2525D1%252582%2525D1%252580%2525D0%2525B0%2525D0%2525BD%2525D0%2525B5%2525D0%2525BD%2525D0%2525B8%2525D0%2525B5-%2525D0%2525B2%2525D0%2525B5%2525D1%252587%2525D0%2525BD%2525D0%2525BE%2525D0%2525B3%2525D0%2525BE-booting%2525D0%2525B0-%2525D0%2525BF%2525D1%252580%2525D0%2525BE%2525D1%252588%2525D0%2525B8%2525D0%2525B2%2525D0%2525BA%2525D0%2525BE%2525D0%2525B9-flash-8-mb-%2525D1%252587%2525D0%2525B5%2525D1%252580%2525D0%2525B5%2525D0%2525B7-jtag-%2525D0%2525B2-%2525D0%2525B4%2525D0%2525BE%2525D0%2525BC%2525D0%2525B0%2525D1%252588%2525D0%2525BD%2525D0%2525B8%2525D1%252585-%2525D1%252583%2525D1%252581%2525D0%2525BB%2525D0%2525BE%2525D0%2525B2%2525D0%2525B8%2525D1%25258F%2525D1%252585%26sa%3DU%26ei%3DazfNVNm4NtWvaczmgvgJ%26ved%3D0CEMQFjAH%26sig2%3Dkt4fg-LWwU1g93feX8vN7Q%26usg%3DAFQjCNHOMTyrOAIkveVkkQzZ
QOOobMIrhA
... and still yet others to a Brazilian page, for which I haven't
found a definite URL. Subsequent generations of translations appear
to be (Spanish & Italian, the second is translated and edited from the
first, which itself derived from pristavka.de) ...
https://translate.google.co.uk/translate?hl=en&ie=UTF8&prev=_t&sl=es&tl=en&u=http://openspa.info/threads/tutorial-recuperar-deco-en-booting-via-jtag.12602/
https://translate.google.co.uk/translate?hl=en&ie=UTF8&prev=_t&sl=it&tl=en&u=http://www.manutek.it/forum/azbox/recuperare-azbox-in-booting-via-jtag-t10174.html
... etc, etc. However, although some versions use resistors to make
the jump, others not, none of these pages mention whether the pin is
being pulled high or low!
However, finally I did discover available on the web a circuit diagram
for Pioneer kit using this CPU (15MB+ download) ...
http://www.go-gddq.com/upload/2014-05/14051416497981.pdf
... and on p46 it shows D11 as being wired as follows (ASCII art
warning - you may need a fixed font for this to display properly):
V+3D
| R1851 = NM (I presume 'not made' = jumper like the Azbox)
---------------------------------0 D11 on CPU
| R1852 = 10k
GND
So it seems D11's being pulled high when the jumper is made, and this
is what enables JTAG functionality on the chip
3) Ooeer missus, can't see a damned thing - not all the connections
go through the board, and the relevant one is within the fourth rank
in from the outer edge, so, even if I removed the heatsink, it would
still be obscured by the body of the CPU itself.
B***er, stuck again.
Time to chase QNAP again ...
<theom...@chiark.greenend.org.uk> wrote:
>
> You don't need the board connected to short the pins together, it's simply a
> check that the JTAG cable is working (it should show 'no devices found' in
> that case).
Yes, the attempt at fetching an ID returns all zeroes ...
>
> You don't need the board connected to short the pins together, it's simply a
> check that the JTAG cable is working (it should show 'no devices found' in
> that case).
C:\TEMP>"C:\Program Files\ZJTAG\zjtag.exe" -probeonly
==============================================
zJTAG EJTAG Debrick Utility v1.0
==============================================
Set I/O speed to 30000 KHz
zJTAG EJTAG Debrick Utility v1.0
==============================================
USB TAP device has been initialized. Please confirm VREF signal
connected!
Press any key to continue... ONCE target board is powered on!
Probing bus ... Done
Detected IR chain Length is 1
Probing bus ... Done
Detected IR chain Length is 1
CPU Chip ID: 00000000000000000000000000000000 (00000000)
*** Unknown or NO CPU Chip ID Detected ***
*** Possible Causes:
1) Router/Modem is not Connected.
2) Router/Modem is not Powered On.
3) Improper JTAG Cable.
4) Unrecognized CPU Chip ID.
*** Unknown or NO CPU Chip ID Detected ***
*** Possible Causes:
1) Router/Modem is not Connected.
2) Router/Modem is not Powered On.
3) Improper JTAG Cable.
4) Unrecognized CPU Chip ID.
> > If I connect VTAR <-> VREF, an LED (red) lights on the TUMPA, and
> > zJTAG behaves a little differently as outlined in the next paragraph,
> > but otherwise I don't observe any difference. Likewise RST<->nSRST
> > doesn't seem to make any difference either.
>
> OK, so you do need VREF.
I suspect it's only for zJTAG so that it knows whether the target
> > zJTAG behaves a little differently as outlined in the next paragraph,
> > but otherwise I don't observe any difference. Likewise RST<->nSRST
> > doesn't seem to make any difference either.
>
> OK, so you do need VREF.
device is on or not. OpenOCD appears to be indifferent.
> Worth probing the TDI and TDO pins with a multimeter and seeing whether the
> voltages change at all (better a scope if you have one). You should see
> TCK, TMS and TDI on the chip change when you run the programming software.
doing this as the ID was queried, but, having just the normal quota of
two hands, it was difficult to get keep the probes stable with one
while I ran the software with the other, and the results were
inconclusive.
> JTAG chains the devices on the board together - TDO from one goes to TDI of
> the next. You need to specify which device in the chain you have. However
> it looks like you have either a broken chain, or a chain of zero devices (if
> you short TDO to TDI). If the chip is successfully connected you'll have
> one or more devices and need to select which one.
>
> It's quite easy to get TDI and TDO mixed up - eg the programmer probably
> outputs on TDI since it expects to feed a TDI input on a chip.
> If it doubt try them both ways.
TDI <-> TDI
TDO <-> TDO
... gives all 1s as the device ID if there is no power to the target
TDO <-> TDO
board, all 0s if there is power, while crossed over ...
TDI <-> TDO
TDO <-> TDI
... gives all 1s as the device ID in both situations.
TDO <-> TDI
From which I conclude that in this case straight through is correct,
as that scheme is responsive to change.
> You should be able to read the chip ID at least, but from there it's still
> an open question whether you can get any further with the open source tools.
checked all the connections using the meter, and having been led to
believe by its output that the TUMPA is working correctly, I'm now
reasonably certain that the reason for my failure thus far is the
following ...
> On Sun, 25 Jan 2015 14:06:12 +0000, Java Jive <ja...@evij.com.invalid>
> wrote:
> >
> > or perhaps I need to set a jumper somewhere on the
> > NMP board to make it respond to JTAG
On Mon, 26 Jan 2015 04:04:26 +0000, Java Jive <ja...@evij.com.invalid>
> > NMP board to make it respond to JTAG
wrote:
>
> This is my current bet, a la AzBox requiring R309 to be shorted to
> enable the JTAG. My bet for the NMP-1000 is short R209, which is in a
> very similar position to R309 on the AzBox. However, to be sure I've
> asked QNAP support ...
I've discovered some more, but not as much as I hoped ...
> enable the JTAG. My bet for the NMP-1000 is short R209, which is in a
> very similar position to R309 on the AzBox. However, to be sure I've
> asked QNAP support ...
To begin with, QNAP have gone coy on me, no reply to my request for
information about enabling the JTAG despite a follow-up reminder. So
yesterday, I tried shorting R209 and it made ... no difference. I was
gutted, I'd been so sure that it would work, but it appears JTAG is
still not enabled, and still there's no meaningful ID coming back.
However, consequently examining more closely the photos of other
boards which are on the net, for example the most documented seems to
be the Azbox ...
http://img571.imageshack.us/img571/6427/93122218.jpg
... led me to realise that anyway the tracks from R309 on the Azbox,
which lead off to the area around rows 11 and 12 of the CPU pins, were
very unlikely to go to the same pins as those from R209 on the
NMP-1000, which are further down the side of the processor and go to
the area around rows 15 and 16.
So I searched for a CPU pinout and eventually found this ...
http://hwdb.mipt.cc/SMP8634/Pinout
... which revealed that the name of pin D11, JTAG_UART#, is the only
one to mention JTAG. Therefore, I think it can be presumed safely
that one of the tracks from R309 on the Azbox PCB goes to this pin.
Consequently, I also presume that if this pin is held to one of Vss or
GND, JTAG is enabled, but if the other, disabled. PCB designers can
thus choose:
:-) Permanently enable
:-( Permanently disable
:-! Enable via jumper or soldered jump
Three questions now remain:
1) To enable JTAG, should D11 be shorted be to Vss or GND?
1) Ought a resistor be used, and if so, what value?
2) Where are the equivalent points on the NMP-1000 PCB?
1 & 2)
Of the various sites quoting this jump for the Azbox, most seem to be
auto-translations of other pages, often themselves auto-translations
of still yet others, making it difficult to work out which page(s)
were originals. Some seem to have derived from a page on a Russian
language German site www.pristavka.de, of which the original no longer
exists. Others refer to this as a possible original ...
https://translate.google.co.uk/translate?sl=ru&tl=en&hl=en&ie=UTF-8&u=http%3A%2F%2Fwww.google.co.uk%2Furl%3Fq%3Dhttp%3A%2F%2Fipbox.com.ua%2Fshowthread.php%2F5219-%2525D1%252583%2525D1%252581%2525D1%252582%2525D1%252580%2525D0%2525B0%2525D0%2525BD%2525D0%2525B5%2525D0%2525BD%2525D0%2525B8%2525D0%2525B5-%2525D0%2525B2%2525D0%2525B5%2525D1%252587%2525D0%2525BD%2525D0%2525BE%2525D0%2525B3%2525D0%2525BE-booting%2525D0%2525B0-%2525D0%2525BF%2525D1%252580%2525D0%2525BE%2525D1%252588%2525D0%2525B8%2525D0%2525B2%2525D0%2525BA%2525D0%2525BE%2525D0%2525B9-flash-8-mb-%2525D1%252587%2525D0%2525B5%2525D1%252580%2525D0%2525B5%2525D0%2525B7-jtag-%2525D0%2525B2-%2525D0%2525B4%2525D0%2525BE%2525D0%2525BC%2525D0%2525B0%2525D1%252588%2525D0%2525BD%2525D0%2525B8%2525D1%252585-%2525D1%252583%2525D1%252581%2525D0%2525BB%2525D0%2525BE%2525D0%2525B2%2525D0%2525B8%2525D1%25258F%2525D1%252585%26sa%3DU%26ei%3DazfNVNm4NtWvaczmgvgJ%26ved%3D0CEMQFjAH%26sig2%3Dkt4fg-LWwU1g93feX8vN7Q%26usg%3DAFQjCNHOMTyrOAIkveVkkQzZ
QOOobMIrhA
... and still yet others to a Brazilian page, for which I haven't
found a definite URL. Subsequent generations of translations appear
to be (Spanish & Italian, the second is translated and edited from the
first, which itself derived from pristavka.de) ...
https://translate.google.co.uk/translate?hl=en&ie=UTF8&prev=_t&sl=es&tl=en&u=http://openspa.info/threads/tutorial-recuperar-deco-en-booting-via-jtag.12602/
https://translate.google.co.uk/translate?hl=en&ie=UTF8&prev=_t&sl=it&tl=en&u=http://www.manutek.it/forum/azbox/recuperare-azbox-in-booting-via-jtag-t10174.html
... etc, etc. However, although some versions use resistors to make
the jump, others not, none of these pages mention whether the pin is
being pulled high or low!
However, finally I did discover available on the web a circuit diagram
for Pioneer kit using this CPU (15MB+ download) ...
http://www.go-gddq.com/upload/2014-05/14051416497981.pdf
... and on p46 it shows D11 as being wired as follows (ASCII art
warning - you may need a fixed font for this to display properly):
V+3D
| R1851 = NM (I presume 'not made' = jumper like the Azbox)
---------------------------------0 D11 on CPU
| R1852 = 10k
GND
So it seems D11's being pulled high when the jumper is made, and this
is what enables JTAG functionality on the chip
3) Ooeer missus, can't see a damned thing - not all the connections
go through the board, and the relevant one is within the fourth rank
in from the outer edge, so, even if I removed the heatsink, it would
still be obscured by the body of the CPU itself.
B***er, stuck again.
Time to chase QNAP again ...
Theo Markettos
Jan 31, 2015, 8:14:38 PM1/31/15
to
In uk.comp.os.linux Java Jive <ja...@evij.com.invalid> wrote:
> On 28 Jan 2015 18:22:58 +0000 (GMT), Theo Markettos
> <theom...@chiark.greenend.org.uk> wrote:
> > OK, so you do need VREF.
>
> I suspect it's only for zJTAG so that it knows whether the target
> device is on or not. OpenOCD appears to be indifferent.
VREF is power to the programmer - it sets up the level shifter to give the
> <theom...@chiark.greenend.org.uk> wrote:
> > OK, so you do need VREF.
>
> I suspect it's only for zJTAG so that it knows whether the target
> device is on or not. OpenOCD appears to be indifferent.
right voltage levels. Without it, you may have no signals.
> Straight through connection ...
> TDI <-> TDI
> TDO <-> TDO
> ... gives all 1s as the device ID if there is no power to the target
> board, all 0s if there is power, while crossed over ...
> TDI <-> TDO
> TDO <-> TDI
> ... gives all 1s as the device ID in both situations.
>
> From which I conclude that in this case straight through is correct,
> as that scheme is responsive to change.
> Three questions now remain:
> 1) To enable JTAG, should D11 be shorted be to Vss or GND?
> 1) Ought a resistor be used, and if so, what value?
> 2) Where are the equivalent points on the NMP-1000 PCB?
disabled permanently though (sawn off during packaging, or by blowing
internal fuses after programming).
> V+3D
> | R1851 = NM (I presume 'not made' = jumper like the Azbox)
> ---------------------------------0 D11 on CPU
> | R1852 = 10k
> GND
>
> So it seems D11's being pulled high when the jumper is made, and this
> is what enables JTAG functionality on the chip
when high?
> 3) Ooeer missus, can't see a damned thing - not all the connections
> go through the board, and the relevant one is within the fourth rank
> in from the outer edge, so, even if I removed the heatsink, it would
> still be obscured by the body of the CPU itself.
that there's good signals on TDI, TCK and TMS, and see if anything comes out of TDO.
> Time to chase QNAP again ...
this...
Theo
Johny B Good
Feb 1, 2015, 10:36:39 AM2/1/15
to
On Sat, 31 Jan 2015 23:28:56 +0000, Java Jive <ja...@evij.com.invalid>
wrote:
Have you not considered installing Voice Recognition software?
--
J B Good
wrote:
--
J B Good
Andy Burns
Feb 1, 2015, 12:44:01 PM2/1/15
to
Java Jive wrote:
> C:\TEMP>"C:\Program Files\ZJTAG\zjtag.exe" -probeonly
>
> ==============================================
> zJTAG EJTAG Debrick Utility v1.0
> ==============================================
>
> Set I/O speed to 30000 KHz
>
> USB TAP device has been initialized. Please confirm VREF signal
> connected!
> Press any key to continue... ONCE target board is powered on!
>
> Probing bus ... Done
>
> Detected IR chain Length is 1
>
> CPU Chip ID: 00000000000000000000000000000000 (00000000)
> *** Unknown or NO CPU Chip ID Detected ***
Seeing you have fun with your TUMPA reminded me I'd bought a TUMPA-lite,
> C:\TEMP>"C:\Program Files\ZJTAG\zjtag.exe" -probeonly
>
> ==============================================
> zJTAG EJTAG Debrick Utility v1.0
> ==============================================
>
> Set I/O speed to 30000 KHz
>
> USB TAP device has been initialized. Please confirm VREF signal
> connected!
> Press any key to continue... ONCE target board is powered on!
>
> Probing bus ... Done
>
> Detected IR chain Length is 1
>
> CPU Chip ID: 00000000000000000000000000000000 (00000000)
> *** Unknown or NO CPU Chip ID Detected ***
I recently replaced my old faithful WRT54GS with a WNDR3800, so I don't
mind fiddling with the old router.
Soldered the pins to the TUMPA, got drivers loader for it.
Had difficulty with braid and solder sucker cleaning out the JP1/JP2
headers on the router.
Soldered pins to JP1 for a TTL-level serial port on the router, wired it
up and checked that ttyS0 worked OK for Linux.
Soldered pins to JP2 for JTAG, wired that up and checked zjtag talked to
the router OK.
Did you try the /L1:3 option to set the clock divider? Mine won't
"speak" without it, I also need /cable:3 for a TUMPA-lite, but you
probably can leave that as default.
Java Jive
Feb 1, 2015, 12:50:38 PM2/1/15
to
Yes, that was one of the first things I tried as described up thread,
though in my case the correct parameter seems to be /L1:149.
On Sun, 01 Feb 2015 17:43:59 +0000, Andy Burns
<usenet....@adslpipe.co.uk> wrote:
>
> Did you try the /L1:3 option to set the clock divider? Mine won't
> "speak" without it, I also need /cable:3 for a TUMPA-lite, but you
> probably can leave that as default.
though in my case the correct parameter seems to be /L1:149.
On Sun, 01 Feb 2015 17:43:59 +0000, Andy Burns
<usenet....@adslpipe.co.uk> wrote:
>
> Did you try the /L1:3 option to set the clock divider? Mine won't
> "speak" without it, I also need /cable:3 for a TUMPA-lite, but you
> probably can leave that as default.
Andy Burns
Feb 1, 2015, 12:54:10 PM2/1/15
to
Java Jive wrote:
> that was one of the first things I tried as described up thread,
> though in my case the correct parameter seems to be /L1:149.
OK, I've not been following closely, but your pasted example failure
> that was one of the first things I tried as described up thread,
> though in my case the correct parameter seems to be /L1:149.
didn't show the /L1 option.
Java Jive
Feb 1, 2015, 4:48:13 PM2/1/15
to
On 01 Feb 2015 01:14:35 +0000 (GMT), Theo Markettos
Incidentally, I've discovered while re-testing that I wasn't correct
when I said that RST <-> nsRST had no effect. When that connection is
made, the ID output is always all 1s.
> Right, sounds like the hardware is mostly OK.
Yes, I'm pretty well convinced of this now.
> > So it seems D11's being pulled high when the jumper is made, and this
> > is what enables JTAG functionality on the chip
>
> Seems so. JTAG_UART# would imply UART mode when low, so perhaps JTAG mode
> when high?
Ah that sounds familiar, but I've searched so many pages over this
recently, that my memory, which is aging anyway, is in something of a
whirl. Perhaps it was this I remember, though I think I remember a
more complete description (Azbox again - this contributor apparently
didn't know about R309 although it was mentioned indirectly up thread,
and, yes indeed, it's stated as being pulled high):
http://www.usbjtag.com/vbforum/archive/index.php?t-7046.html
"I also remember reading that the jtag header also functions as a
secondary UART for logging. There may be another jumper which
enables JTAG or UART2."
Also ...
http://www.usbjtag.com/vbforum/showthread.php?t=6293&highlight=AzboxPremium&page=2
"Please note, after JTAG program the original boot, you need to
remove JTAG to power on the box. When JTAG software is running
and JTAG connected, the box will not power on. That is expected
since JTAG is still talking to the box and thus regular boot up
sequence is not executed."
> > 3) Ooeer missus, can't see a damned thing - not all the connections
> > go through the board, and the relevant one is within the fourth rank
> > in from the outer edge, so, even if I removed the heatsink, it would
> > still be obscured by the body of the CPU itself.
>
> The only thing I can suggest is to scope TDI and TDO into the chip and check
> that there's good signals on TDI, TCK and TMS, and see if anything comes out of TDO.
Used to have a second-hand Tektronics 'scope - which I'd swapped for
a cowboy jacket, my local electronics guy was keen on C&W! Although
it had some typical second-hand quirks, it proved useful over several
years, until one time I went to use it and found it dead, and
unfortunately I've never been able to afford to replace it.
> > Time to chase QNAP again ...
>
> Go easy on them, you don't get a whole lot of support for consumer kit like
> this...
If only I could shake, oh ever so gently you may be sure, someone by
the neck until the necessary information was forthcoming! However, to
be fair, they have been very helpful, considering they don't
officially support the device any more.
I'll probably have another try tonight or tomorrow. Bit tired
tonight, walking back up the drive from my afternoon walk, I noticed
that a tree had half-uprooted in the recent gales, we had another last
night, and was threatening the wall between my property and the next,
so I spent an unscheduled frantic hour or two hand-sawing the most
threatening branches off. More to do tomorrow.
<theom...@chiark.greenend.org.uk> wrote:
>
> VREF is power to the programmer - it sets up the level shifter to give the
> right voltage levels. Without it, you may have no signals.
Noted for future reference.
>
> VREF is power to the programmer - it sets up the level shifter to give the
> right voltage levels. Without it, you may have no signals.
Incidentally, I've discovered while re-testing that I wasn't correct
when I said that RST <-> nsRST had no effect. When that connection is
made, the ID output is always all 1s.
> Right, sounds like the hardware is mostly OK.
> > So it seems D11's being pulled high when the jumper is made, and this
> > is what enables JTAG functionality on the chip
>
> Seems so. JTAG_UART# would imply UART mode when low, so perhaps JTAG mode
> when high?
recently, that my memory, which is aging anyway, is in something of a
whirl. Perhaps it was this I remember, though I think I remember a
more complete description (Azbox again - this contributor apparently
didn't know about R309 although it was mentioned indirectly up thread,
and, yes indeed, it's stated as being pulled high):
http://www.usbjtag.com/vbforum/archive/index.php?t-7046.html
"I also remember reading that the jtag header also functions as a
secondary UART for logging. There may be another jumper which
enables JTAG or UART2."
Also ...
http://www.usbjtag.com/vbforum/showthread.php?t=6293&highlight=AzboxPremium&page=2
"Please note, after JTAG program the original boot, you need to
remove JTAG to power on the box. When JTAG software is running
and JTAG connected, the box will not power on. That is expected
since JTAG is still talking to the box and thus regular boot up
sequence is not executed."
> > 3) Ooeer missus, can't see a damned thing - not all the connections
> > go through the board, and the relevant one is within the fourth rank
> > in from the outer edge, so, even if I removed the heatsink, it would
> > still be obscured by the body of the CPU itself.
>
> The only thing I can suggest is to scope TDI and TDO into the chip and check
> that there's good signals on TDI, TCK and TMS, and see if anything comes out of TDO.
a cowboy jacket, my local electronics guy was keen on C&W! Although
it had some typical second-hand quirks, it proved useful over several
years, until one time I went to use it and found it dead, and
unfortunately I've never been able to afford to replace it.
> > Time to chase QNAP again ...
>
> Go easy on them, you don't get a whole lot of support for consumer kit like
> this...
the neck until the necessary information was forthcoming! However, to
be fair, they have been very helpful, considering they don't
officially support the device any more.
I'll probably have another try tonight or tomorrow. Bit tired
tonight, walking back up the drive from my afternoon walk, I noticed
that a tree had half-uprooted in the recent gales, we had another last
night, and was threatening the wall between my property and the next,
so I spent an unscheduled frantic hour or two hand-sawing the most
threatening branches off. More to do tomorrow.
Java Jive
Feb 1, 2015, 5:01:38 PM2/1/15
to
Because I was testing shorting TDI & TDO and therefore not constrained
by the speed of the target NMP-1000 board.
On Sun, 01 Feb 2015 17:54:08 +0000, Andy Burns
<usenet....@adslpipe.co.uk> wrote:
>
> OK, I've not been following closely, but your pasted example failure
> didn't show the /L1 option.
by the speed of the target NMP-1000 board.
On Sun, 01 Feb 2015 17:54:08 +0000, Andy Burns
<usenet....@adslpipe.co.uk> wrote:
>
> OK, I've not been following closely, but your pasted example failure
> didn't show the /L1 option.
Java Jive
Feb 1, 2015, 5:40:54 PM2/1/15
to
Absolutely not ...
I was one of the people who tested Via Voice voice recognition
software at my last place of work some years ago. These are excerpts
from an email I sent to my boss ...
"Just to soften you up for irate mails from partners ... maybe we
should start a web-page like the one for the Newton Message Pad!
This is a bit of a farce really, perhaps the active mike will be
better, but this is a relatively quiet environment. I don't think
this is going to increase my productivity yet ...
Also, Microsoft Word seems to hang after a while, I suspect when it
tries to autosave ...
Via Voice = While Boris, By our boys, the Higher Boris, wire wars
(you'd think it would recognise its own name wouldn't you?)
Andy (surname deleted to protect the guilty) = Andy sedate, and the
best they eat, Andy's Derek, Andy's Date
Create memo launches Outlook = Create my launches own
Much = Mark Mark Mark EDGE mark EDGE and Hutch march for Christ's sake
(I see it understood that) mark she
Scratch that = a expects, scratch mark, scratch back at, square that
Hooray = raw Rennie who re-he who re-Harare at Ra Harare Harare
Unfair = one ferret
I still haven't worked out what these were originally supposed to be:
mirror any rival will stock the all stop all stock are banned are
planned higher bond higher bond hike bond high end higher than
are bound (firm's name deleted to protect the guilty) already already
already go to it this is the bit that the pots this is that it go to
this is but a it this this go to stop a long stop boring beginning of
long Liner Liner Previous will. Jesus, I am going to boil this piece
of broccoli (ah, I see it understood that, right enough) (Brocoli was
the name of the on-screen cartoon character that was the VV equivalent
of a bent paperclip) and a large band had that look at it anymore.
it catches could talk as they could cabbages could talk are said it
cabbages could talk eyes said it cabbages could walk IDE said it
cabbages could talk are a said it cabbages could talk the three said
it cabbages I said it cabbages could talk I said it cabbages could
talk ice any cabbages could talk a i z e of cabbages it could talk a
has said if cabbages could talk are three sets are a said it cabbages
Irene said it cabbages could talk Ra said in cabbages court to
walk cabbages Corps at talk IEA said it cabbages chord talk cabbages
could talk I said it cabbages could talk I said it cabbages could talk
I said cabbages could talk I said it cabbages could talk I've said it
cabbages could talk. I said: "if cabbages could talk" hooray (this
word had to be put in by hand, and I've forgotten what the end of the
sentence was going to be now)
Regards G poll (sic, very sic)"
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.703 / Virus Database: 459 - Release Date: 10/06/2004
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.4 - Release Date: 22/12/2004
On Sun, 01 Feb 2015 15:36:37 +0000, Johny B Good
<johnny...@invalid.ntlworld.com> wrote:
>
> Have you not considered installing Voice Recognition software?
--
I was one of the people who tested Via Voice voice recognition
software at my last place of work some years ago. These are excerpts
from an email I sent to my boss ...
"Just to soften you up for irate mails from partners ... maybe we
should start a web-page like the one for the Newton Message Pad!
This is a bit of a farce really, perhaps the active mike will be
better, but this is a relatively quiet environment. I don't think
this is going to increase my productivity yet ...
Also, Microsoft Word seems to hang after a while, I suspect when it
tries to autosave ...
Via Voice = While Boris, By our boys, the Higher Boris, wire wars
(you'd think it would recognise its own name wouldn't you?)
Andy (surname deleted to protect the guilty) = Andy sedate, and the
best they eat, Andy's Derek, Andy's Date
Create memo launches Outlook = Create my launches own
Much = Mark Mark Mark EDGE mark EDGE and Hutch march for Christ's sake
(I see it understood that) mark she
Scratch that = a expects, scratch mark, scratch back at, square that
Hooray = raw Rennie who re-he who re-Harare at Ra Harare Harare
Unfair = one ferret
I still haven't worked out what these were originally supposed to be:
mirror any rival will stock the all stop all stock are banned are
planned higher bond higher bond hike bond high end higher than
are bound (firm's name deleted to protect the guilty) already already
already go to it this is the bit that the pots this is that it go to
this is but a it this this go to stop a long stop boring beginning of
long Liner Liner Previous will. Jesus, I am going to boil this piece
of broccoli (ah, I see it understood that, right enough) (Brocoli was
the name of the on-screen cartoon character that was the VV equivalent
of a bent paperclip) and a large band had that look at it anymore.
it catches could talk as they could cabbages could talk are said it
cabbages could talk eyes said it cabbages could walk IDE said it
cabbages could talk are a said it cabbages could talk the three said
it cabbages I said it cabbages could talk I said it cabbages could
talk ice any cabbages could talk a i z e of cabbages it could talk a
has said if cabbages could talk are three sets are a said it cabbages
Irene said it cabbages could talk Ra said in cabbages court to
walk cabbages Corps at talk IEA said it cabbages chord talk cabbages
could talk I said it cabbages could talk I said it cabbages could talk
I said cabbages could talk I said it cabbages could talk I've said it
cabbages could talk. I said: "if cabbages could talk" hooray (this
word had to be put in by hand, and I've forgotten what the end of the
sentence was going to be now)
Regards G poll (sic, very sic)"
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.703 / Virus Database: 459 - Release Date: 10/06/2004
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.4 - Release Date: 22/12/2004
On Sun, 01 Feb 2015 15:36:37 +0000, Johny B Good
<johnny...@invalid.ntlworld.com> wrote:
>
> Have you not considered installing Voice Recognition software?
--
Johny B Good
Feb 1, 2015, 9:20:12 PM2/1/15
to
On Sun, 01 Feb 2015 22:40:52 +0000, Java Jive <ja...@evij.com.invalid>
wrote:
>
So that's a "No" then. :-(
Ah, yes! So you said so at the top of your missive.
How about a "Robot Hand" ?
--
J B Good
wrote:
>
>On Sun, 01 Feb 2015 15:36:37 +0000, Johny B Good
><johnny...@invalid.ntlworld.com> wrote:
>>
>> Have you not considered installing Voice Recognition software?
><johnny...@invalid.ntlworld.com> wrote:
>>
>> Have you not considered installing Voice Recognition software?
Ah, yes! So you said so at the top of your missive.
How about a "Robot Hand" ?
--
J B Good
Java Jive
Feb 1, 2015, 9:27:14 PM2/1/15
to
Why stop at one, why not two, then I'd be able to toss myself off as I
work!
work!
Java Jive
Feb 2, 2015, 7:08:37 AM2/2/15
to
Wrote to QNAP last night, but assuming the worst in the meantime, can
you spot the UARTs on the board? Or are they and the JTAG built-in to
the CPU?
http://www.macfh.co.uk/Temp/QNAP_NMP-1000_Board.png
I was thinking that if I could identify them, perhaps I might be able
to work all the way back towards the CPU ...
On Sun, 01 Feb 2015 21:48:11 +0000, Java Jive <ja...@evij.com.invalid>
wrote:
>
you spot the UARTs on the board? Or are they and the JTAG built-in to
the CPU?
http://www.macfh.co.uk/Temp/QNAP_NMP-1000_Board.png
I was thinking that if I could identify them, perhaps I might be able
to work all the way back towards the CPU ...
On Sun, 01 Feb 2015 21:48:11 +0000, Java Jive <ja...@evij.com.invalid>
wrote:
>
> On 01 Feb 2015 01:14:35 +0000 (GMT), Theo Markettos
> <theom...@chiark.greenend.org.uk> wrote:
> >
> > Go easy on them, you don't get a whole lot of support for consumer kit like
> > this...
> <theom...@chiark.greenend.org.uk> wrote:
> >
> > Go easy on them, you don't get a whole lot of support for consumer kit like
> > this...
Johny B Good
Feb 2, 2015, 12:53:24 PM2/2/15
to
On Mon, 02 Feb 2015 02:27:12 +0000, Java Jive <ja...@evij.com.invalid>
wrote:
<Spoiler space
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
[1] "The Big Bang Theory" Season 4 episode 1 for anyone interested.
--
J B Good
wrote:
>On Mon, 02 Feb 2015 02:20:11 +0000, Johny B Good
><johnny...@invalid.ntlworld.com> wrote:
>>
>> How about a "Robot Hand" ?
>Why stop at one, why not two, then I'd be able to toss myself off as I
>work!
>
Ah! So you've seen "The Robotic Manipulation" episode then?[1]
><johnny...@invalid.ntlworld.com> wrote:
>>
>> How about a "Robot Hand" ?
>Why stop at one, why not two, then I'd be able to toss myself off as I
>work!
>
<Spoiler space
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
[1] "The Big Bang Theory" Season 4 episode 1 for anyone interested.
--
J B Good
Theo Markettos
Feb 3, 2015, 1:02:59 PM2/3/15
to
In uk.comp.os.linux Java Jive <ja...@evij.com.invalid> wrote:
> Wrote to QNAP last night, but assuming the worst in the meantime, can
> you spot the UARTs on the board? Or are they and the JTAG built-in to
> the CPU?
> http://www.macfh.co.uk/Temp/QNAP_NMP-1000_Board.png
They'll be inside the CPU. A UART hasn't been a standalone component for a
> you spot the UARTs on the board? Or are they and the JTAG built-in to
> the CPU?
> http://www.macfh.co.uk/Temp/QNAP_NMP-1000_Board.png
very long time.
Theo
merkin
Mar 19, 2015, 8:04:57 PM3/19/15
to
http://www.usbjtag.com/wordpress/
you need to enable ejtag with the jumper. here is envision schmatic
https://drive.google.com/file/d/0B0489aMeZ10HYURjZUgtSVJ5S0E/view?usp=sharing
and here is smp8634 datasheet
https://drive.google.com/file/d/0B0489aMeZ10HY0JlSEdSQTRmTUk/view?usp=sharing
i have also used standard "wiggler" jtag with openocd. use x300t board file, but adapt for your board. all you need to do is flash the boot. do not flash the entire bin with parallel port jtag device. it will take too long. just flash the boot, then use tftp or uart.
0 new messages