JTAG-ing - Anyone able to advise?

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,
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.


--
[email protected] | Martin Gregorie
gregorie. | Essex, UK
org |

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 next release of the driver does ...

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
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

On 27 Sep 2014 00:27:50 +0100 (BST), Theo Markettos
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/downlo...M1270ZT144.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/Real...AGTutorial.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
================================================== =======
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

In uk.comp.os.linux Java Jive 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/Real...AGTutorial.pdf

That sounds plausible. So can you get hold of the 'monice' tool, and a JTAG
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

In uk.tech.digital-tv Theo Markettos 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,
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

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-mu...2c-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_Wi...UMPA_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/TIAO...dapterUser.pdf

.... have no apparent counterparts in the MIPS EJTAG connections ...

http://wiki.openwrt.org/doc/hardware...ag#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
wrote:

In uk.tech.digital-tv Theo Markettos 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 -
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.
--
================================================== =======
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
================================================== =======
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

In uk.comp.os.linux Java Jive wrote:
http://www.diygadget.com/tiao-usb-mu...2c-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
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.

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.

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).

Theo

On 23 Jan 2015 20:48:50 +0000 (GMT), Theo Markettos
wrote:

In uk.comp.os.linux Java Jive 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
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:
---------------

[email protected]:/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:
--------------

[email protected]:/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'

[email protected]:/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.
--
================================================== =======
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
================================================== =======
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

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
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.
--
================================================== =======
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
================================================== =======
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