My command line tools

[segher]

http://xcore.com/projects/xs1-disassemb ... jtag-tools

These tools are useful if you cannot use the SDK for some reason, or prefer not to.

Please tell me what you think about it, if you have idea for improvements, or
maybe even have patches :-)


Segher

[m_y]

Please tell me what you think about it

It's a good start - looking forward to seeing how it develops.

Do you plan on making a drop-in replacement for each of the XMOS tools or will this be a separate/incompatible toolchain?

[segher]

It's a good start - looking forward to seeing how it develops.

Well, next step is a cross Forth system, and then a self-hosting one.

Do you plan on making a drop-in replacement for each of the XMOS tools or will this be a separate/incompatible toolchain?

Why would I want to make direct replacements? That sounds like a big waste of time!

Nothing in this is a drop-in replacement for any of the SDK things as far as I can see.
Here are some of the differences:

My assembler is a Forth-style assembler (that is, less syntax, more whitespace, op
comes last, you have high-level flow control, and the full host interpreter is available).

I use binary files directly everywhere, not object files.

I am totally not interested in step debuggers (I never use them). I might do some
basic profiling tools though.

I am not going to write a compiler backend -- a little bit too much work, this is
just a hobby right :-)

Some of the JTAG stuff might be similar to the SDK tools; I don't know, since I cannot
run the SDK on any of my desktops / laptops (they aren't x86). I doubt they are really
much alike though.

All in all, it's a collection of small pointy tools, instead of one huge 500-function swiss
army knife. It has everything I currently need, so I don't miss all the "missing" features :-)
I certainly can be convinced to add some though -- any requests?


Segher

[m_y]

It's a good start - looking forward to seeing how it develops.

Well, next step is a cross Forth system, and then a self-hosting one.

I'm looking forward more now. I like Forth, or rather I like the principles underlying it. Which dialect?

Do you plan on making a drop-in replacement for each of the XMOS tools or will this be a separate/incompatible toolchain?

Why would I want to make direct replacements? That sounds like a big waste of time!

I agree, and that's why I asked. OTOH, some people might suggest a full set of "open" replacements would be good for its own sake.

[segher]

I'm looking forward more now. I like Forth, or rather I like the principles underlying it. Which dialect?

ISO Forth (aka ANS Forth) + extensions. It generates (not very much ;-) ) optimised native
code, not threaded VM code.

Do you plan on making a drop-in replacement for each of the XMOS tools or will this be a separate/incompatible toolchain?

Why would I want to make direct replacements? That sounds like a big waste of time!

I agree, and that's why I asked. OTOH, some people might suggest a full set of "open" replacements would be good for its own sake.

I even agree with that sentiment, but that's waaaaay too much work for too little gain, and
frankly not as interesting.

I pushed an update to git just now; it pretty much finishes the assembler features
(although of course most insns aren't implemented yet), and the example code says
"hi" now.


Segher

[jhrose]

I'm attempting a port of segher's JTAG tools to Win32 and have run into a problem. While my ported JTAG tools in essence run on Win32, what I get running regs.exe for example is 0xffffffff from each register location.

I'm using MSVC6.0 and linking with libusb-win32 version 1.2.1.0 [a version based on the older libusb 0.1, as the Windows port is not yet integrated with the newer libusb 1.0 version]. Part of my port includes a "shim layer" between the new and older APIs, but I do not believe any significant errors are present.

I think the problem is related to the on-board RESET_ logic from the FTDI2232D to the XS-1 on my XC-1. In the schematics there are differences between my XC-1 and an XC-1A at the TRST_ and RESET_ logic that are probably significant.

The critical line of code appears to be:

Code: Select all

 // Switch to MPSSE mode.
  err = libusb_control_transfer(device, 0x41, 0x0b, 0x020b, IFACE, 0, 0, 0);

in which a SIO_SET_BITMODE_REQUEST request (0xb) is sent with a value (BITMODE_MPSSE 0x0200 | bitmask 0x0b) to the FTDI interface out endpoint. I believe the bitmask sets the JTAG line direction (TDI etc.) at ADBUS0:3 (though this is also done with a following jtag_write 0x80 command). But it is not possible to set the TRST_ and RESET_ direction and value at ACBUS0:1 and RESET_ gets driven such that my XC1.Q12 is gated and the XS-1 chip has a SYSTEM_RESET (evident by LED17 [PLL_LOCK] extinguishing).

It might be the ported JTAG tools work fine on an XC-1A, with its different reset logic. As xrun works fine [with or without the --noreset option], I imagine there is a way to select MPSSE mode with libusb without driving RESET_? Or can someone point me at any hints/docs/sources on driving the JTAG at the XS-1 (through the FTDI2232D)?

Thanks

[pytey]

It might be the ported JTAG tools work fine on an XC-1A, with its different reset logic.

Yes, I've been using segher's tools on OS X with the XC-1A with no problems.
Funnily enough, only yesterday I was trying his tools with an XC-1 but every command I tried caused my XC-1 to reset, I spoke to segher about this yesterday on IRC and he also said was probably different reset logic between the XC-1 and XC-1A.
I'll take another look at it later and provide some more info for segher.

-- pytey.

[segher]

It looks like XC-1 has the SRST (ACBUS1) polarity switched, relative to XC-1A;
TRST is the same as on XC-1A. Both drive both these signals as outputs.

Are you sure the board resets on the "set bit-bang" command already?

[jhrose]

Are you sure the board resets on the "set bit-bang" command already?

Yes when a value of 2 (bit-bang mode MPSSE) is given; whereas giving a value of 0 (bit-bang mode reset) the 2232 does not drive ACBUS1. I tested a number of times by single stepping through the code while watching Q12 with a multimeter.

The FTDI2232D datasheet describes the different MPSSE modes and how the lines are used, so my thoughts are to first set-up the 2232 in a different mode to program ACBUS0:1 to output value 0 before secondly sending the "bit-bang mode MPSSE" command. According to the datasheet (section 3.3) by default the 2232 comes up in RS232-uart mode, but this might be changed by values stored in the attached 93C46 EEPROM. Are the XC-1 EEPROM values published - or has anyone snooped them? And are different assertion sequences of TRST_/RESET_/DEBUG documented, showing how they affect start-up states in the XS-1?

[segher]

Are you sure the board resets on the "set bit-bang" command already?

Yes when a value of 2 (bit-bang mode MPSSE) is given; whereas giving a value of 0 (bit-bang mode reset) the 2232 does not drive ACBUS1. I tested a number of times by single stepping through the code while watching Q12 with a multimeter.

Those pins default to input. On the XC-1, GPIOH1 is connected directly to the gate of Q12. The
2232 very weakly pulls the line up in input mode, so it will assert RESET# :-(

But why doesn't it do that at bootup already then? I'm missing something here, I guess.

The FTDI2232D datasheet describes the different MPSSE modes and how the lines are used, so my thoughts are to first set-up the 2232 in a different mode to program ACBUS0:1 to output value 0 before secondly sending the "bit-bang mode MPSSE" command.

This should really not be necessary; I don't think the official tools do this either.

According to the datasheet (section 3.3) by default the 2232 comes up in RS232-uart mode, but this might be changed by values stored in the attached 93C46 EEPROM. Are the XC-1 EEPROM values published - or has anyone snooped them? And are different assertion sequences of TRST_/RESET_/DEBUG documented, showing how they affect start-up states in the XS-1?

TRST# resets the JTAG state machine. RESET# is a chip reset. I don't know what DEBUG
does, it's a bidirectional signal, all info I've found on it is that it has something to do with
multi-chip debug synchronisation. Or something :-)

On an XC-1A, TRST# is wired up to set the boot mode pin BS0, so that when you assert RESET#
while holding TRST# asserted, the chip boots in "JTAG boot mode" (which pretty much means:
do nothing, just halt, let the debugger figure it out). XC-1 does not have this.

Let me know if you get any further,


Segher