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
My command line tools
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
-
- Experienced Member
- Posts: 69
- Joined: Mon May 17, 2010 10:19 am
It's a good start - looking forward to seeing how it develops.segher wrote:Please tell me what you think about it
Do you plan on making a drop-in replacement for each of the XMOS tools or will this be a separate/incompatible toolchain?
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
Well, next step is a cross Forth system, and then a self-hosting one.m_y wrote: It's a good start - looking forward to seeing how it develops.
Why would I want to make direct replacements? That sounds like a big waste of time!Do you plan on making a drop-in replacement for each of the XMOS tools or will this be a separate/incompatible toolchain?
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
-
- Experienced Member
- Posts: 69
- Joined: Mon May 17, 2010 10:19 am
I'm looking forward more now. I like Forth, or rather I like the principles underlying it. Which dialect?segher wrote:Well, next step is a cross Forth system, and then a self-hosting one.m_y wrote:It's a good start - looking forward to seeing how it develops.
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 wrote:Why would I want to make direct replacements? That sounds like a big waste of time!Do you plan on making a drop-in replacement for each of the XMOS tools or will this be a separate/incompatible toolchain?
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
ISO Forth (aka ANS Forth) + extensions. It generates (not very much ;-) ) optimised nativem_y wrote:I'm looking forward more now. I like Forth, or rather I like the principles underlying it. Which dialect?
code, not threaded VM code.
I even agree with that sentiment, but that's waaaaay too much work for too little gain, andI 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.Why would I want to make direct replacements? That sounds like a big waste of time!Do you plan on making a drop-in replacement for each of the XMOS tools or will this be a separate/incompatible toolchain?
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
-
- Active Member
- Posts: 40
- Joined: Mon Dec 14, 2009 11:18 am
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: 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
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);
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
-
- New User
- Posts: 3
- Joined: Mon Mar 08, 2010 3:42 pm
Yes, I've been using segher's tools on OS X with the XC-1A with no problems.jhrose wrote: It might be the ported JTAG tools work fine on an XC-1A, with its different reset logic.
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.
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
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?
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?
-
- Active Member
- Posts: 40
- Joined: Mon Dec 14, 2009 11:18 am
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.Are you sure the board resets on the "set bit-bang" command already?
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?
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
Those pins default to input. On the XC-1, GPIOH1 is connected directly to the gate of Q12. Thejhrose wrote: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.Are you sure the board resets on the "set bit-bang" command already?
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.
This should really not be necessary; I don't think the official tools do this either.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.
TRST# resets the JTAG state machine. RESET# is a chip reset. I don't know what DEBUGAccording 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?
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