Page 2 of 3

Re: Documents detailing XTAG interface?

Posted: Fri Apr 27, 2012 3:12 pm
by segher
LyleHaze wrote:Porting the code has gone very well, my biggest problem right now is decoding the libusb/2232 calls back into basic bit operations.
Why do you need to?

Code: Select all

static void add_queue_out(u32 tms, u32 out, u32 n)
should output the low N bits of TMS and OUT (low bit first);

Code: Select all

static void add_queue_in(u32 tms, u32 out, u32 *in, u32 n)
does the same, but also inputs N bits to *IN;

Code: Select all

static void jtag_set_reset_lines(u8 val)
sets TRST active (i.e., low) if VAL&1, not if not; and
RST active if VAL&2, not if not.

Code: Select all

void jtag_synch(void)
is a no-op if you don't buffer stuff; make sure it flushes everything if
you do buffer things.

FWIW, soon it will be more obvious how to add other JTAG controllers
to the code ;-)
I have looked online and found very little in the way of documents on the 2232 as a JTAG device. Lots of people using it (or were), but very little info on the lower-level details.
They call it "MPSSE". There is a document detailing the commands. But you
do not need it, and be happy :-)
Since libusb is foreign to my OS,
AmigaOS?

Cheers,


Segher

Re: Documents detailing XTAG interface?

Posted: Sat Apr 28, 2012 3:01 am
by LyleHaze
Well, when you put it that way, you make it look easy! ;)

It's working great. I ported over most of the code in dis-xs1-81619b9 except for term.
I still have a bit of cleanup to do, but I am quite impressed with how well it works so far.

So I'll play with it for a few days, clean up my edits, and go from there.

As I understand GPL, I am required to make the source available, to include the GPL
license information with those sources, and not make any money from your works.

I will also credit you as the author of these tools, with a (small) note beneath giving me credit for the Amiga port.

If ANY of this is incorrect or could be improved upon, just let me know!

I cannot thank you enough for your help, and for making these tools available.

Next up for me (after taking a few days to play with my MIDI projects) will be to write a
"Hello World" LED flashing program for this chip, and try to download and run it with your tools.
I HATE running windows.. but at this point it is necessary.

Then I'll have to try to figure out if there is a command-line XCORE assembler that could be ported. We don't have Eclipse, and we will not have it anytime soon. (TRYING to keep from going three steps ahead)

Oh, in case I forgot to tell you.. THANK YOU! THANK YOU.. THANK YOU!!

Lyle

Re: Documents detailing XTAG interface?

Posted: Sun Apr 29, 2012 3:58 am
by segher
LyleHaze wrote:Well, when you put it that way, you make it look easy! ;)
Heh. Great to hear it works well for you now.

What programs do you use? runxe (or "bare" run)? All the rest is for debug
(which is, erm, very useful :-) )
As I understand GPL, I am required to make the source available,
You have to make it available to everyone you give binaries to, yes. It is
easiest for everyone if you just give the code to the whole wide world ;-)
to include the GPL license information with those sources,
Yes; it's already there, in file COPYING.
and not make any money from your works.
You are allowed to ask whatever money you want for it. If you do ask
money for it, you have to distribute the source code yourself, you're
not allowed to simply point at me. And of course you have to properly
note what parts you did not write yourself, and who then did that, etc.
I cannot thank you enough for your help, and for making these tools available.
My pleasure, it is great to see it is useful for people :-)
Then I'll have to try to figure out if there is a command-line XCORE assembler that could be ported.
There is none available as far as I know. Maybe XMOS can open source it if you smile
sweetly ;-)

Or someone could port binutils, perhaps. That would be nice to have!

I can perhaps merge your changes back, btw. Let me know if you'd like that.

Re: Documents detailing XTAG interface?

Posted: Sun Apr 29, 2012 5:32 am
by LyleHaze
segher wrote: Heh. Great to hear it works well for you now.

What programs do you use? runxe (or "bare" run)? All the rest is for debug
(which is, erm, very useful :-) )

Promise not to laugh? None at all, yet. I have not even successfully created
an XCore project.
When the manufacturer made the first run of our motherboard, they plugged
an XTAG programming device in to the socket, plugged a "protoboard" with
about 32 LED drivers into the Xorro slot, and "proved" the design with a
short program they downloaded from their laptop. So my first design goal
was to get access from an AmigaOS command line. Just today I requested
the project code they used for that demo, so that I can load it from these
new utilities. We also have a built-in LED off each core on the motherboard,
and the next step is to modify that project to flash those internal LEDs.
So, if I have appeared to be inexperienced, then you are VERY correct.
segher wrote:
LyleHaze wrote:Then I'll have to try to figure out if there is a command-line XCORE assembler that could be ported.
There is none available as far as I know. Maybe XMOS can open source it if you smile
sweetly ;-)
Actually the project leader went looking today and found the code for the comand line compiler and utils.
It looks like a big project to port over. Since this new Amiga also runs Debian, we may just
use the available tools there for a while.

What I do intend is to add OS level support for resource allocation, to prevent multiple tasks from using the XMOS chip at the same time. Then adding the ability to "run" or "runxe" code into the device just by double-clicking the icon on the executable. This will make different apps more user-friendly. Finally, I'll probably write a GUI window that offers an animated color view of the pins and registers, both as a debugging tool and as eye-candy.
segher wrote: Or someone could port binutils, perhaps. That would be nice to have!
At this time I could only guess what utils you might have or need.. Complete newbie.
segher wrote: I can perhaps merge your changes back, btw. Let me know if you'd like that.
Right this second It's all too messy. I need to clean up my edits.
But I think it's worth doing. I have already been asked if these tools can be used by other
Amigas that don't have an onboard XMOS chip, so support for our own usb.device would be
the third option to merge in.

I have more questions (of course). But these will probably sort themselves out as I get in to the
dev SDK on windows.. The code can scan regs, sregs, pregs, psregs, WTF?
I could GUESS that some are registers, some are the states of I/O pins, possibly some are tri-state status or force options.. More will be revealed as I begin to study.

I'll need to figure out how to create a project without the SDK actually scanning the device, since I will NOT be adding a XTAG adapter to my windows machine.. I know it's an XS1-L2, but there are a few to choose from when creating a project. Again, this will be easier if/when I get the original demo project code here.

Interesting, when they designed this XS1-L2 into the motherboard, they set it up for a very FAST link to the CPU. It has a 16 bit data bus direct to the CPU local bus, as well as a few other lines. I believe it is supposed to appear as RAM to the processor. It passes most of the other signals off to an "XMOS Expansion Slot" (we call it Xorro for historical purposes). So it appears the designers envision the builtin core as a very fast interface between the CPU and additional XCores. Have you seen something like this before? I'm wondering (1) if we have existing designs to learn from, and (2) if this will give us a performance advantage over USB linked devices. I attached a simple diagram of our connection setup a few messages back.

I still have a steep learning curve ahead of me, but having working tools on the native machine is already a great help.

Sleep, I REALLY need sleep. ;)
LyleHaze

Re: Documents detailing XTAG interface?

Posted: Sun Apr 29, 2012 12:11 pm
by LyleHaze
More details, more questions..
I have folded the Amiga specific changes back into your original source code.
I do NOT claim to be very good at it, as I'm sure you'll see soon enough.

Major edits as follows:
90% are in jtag.c, using simple #if defined() to remove buffering and adapt
my bit-banged code. I tried to keep it from getting too messy. You may or may not agree that I was successful.

I created a separate makefile-amiga. I never learned how to do advanced (or even average) makefiles. I don't mind messing up MY copy as long as I can stay out of yours. If you want to fix mine up, feel free. :)

The only other edits were to handle compiler warnings about printing longs without an l qualifier on the conversion character. As I added these I commented out the originals.. So if you want to keep my edits or revert, it should be easy edits either way.

There are two executables that I could not compile. "term", which I did not even try, and "runxe", which needs sys/mman.h. If I knew what it's needing, maybe I could come up with a replacement. So far I have not even looked.
I will probably come up with a term-like program for the Amiga, the separate executables I have now may also be useful.

I have run each.. with a few surprises. all the regs variants show most or all zeros. a few regs have random values. The ID reg at the bottom increments from 0 to 7, this gives me some confidence that I'm reading data well.
I took a dump and a dump-rom.. I expected all 0 or all FF.. got weird repeating patterns instead. Maybe my changes broke something? Would be happy to post or E-mail the output if you're interested in seeing it.
Ran Resources for the first time this morning. There are the output regs I was looking for! Nice to almost recognize something.

If you'd like the code back to make sure I didn't break it (or bend it too badly).. All I need is an E-Mail address. You can reach me at lylehaze(at)gmail(dot)com if you'd prefer to avoid posting your E-mail on the forum.

Switching cores.. does not seem to be working for me. But since there's not much going on in the cores, how could I be sure? I assume just adding "-j 1" to the command line would (should) show the second core?

Also -l or --list shows nothing. Since I have no idea what I'm looking for, this is probably my own ignorance.
By "debug devices" are you listing USB based tools? I could understand why there would be none.

Hopefully I'll get some code to load up and try to run soon. I'm hoping that run will be easy enough to figure out.

Thanks again.. progress continues.

LyleHaze

Re: Documents detailing XTAG interface?

Posted: Mon Apr 30, 2012 12:50 am
by JohnWilson
segher wrote:
LyleHaze wrote:Then I'll have to try to figure out if there is a command-line XCORE assembler that could be ported.
There is none available as far as I know. Maybe XMOS can open source it if you smile
sweetly ;-)

Or someone could port binutils, perhaps. That would be nice to have!
So xas is nothing to do with GPLed code? I tried building the binutils source in the GPL-compliance section of the XMOS web site and I get an apparently vanilla gas which doesn't seem to have heard of the XS1, but maybe I'm doing it wrong. This would be a real shame if so though -- if the documentation is really complete then xas is a toy assembler, with no macros or irp or rept or even if/then (using the C preprocessor misses the point -- no looping or conditionals within macros or access to the assembler's symbol table) ... and it would be nice to be able to add that stuff (or enable it if already present) w/o having to write a new XS1 assembler from scratch.

Re: Documents detailing XTAG interface?

Posted: Mon Apr 30, 2012 3:59 am
by segher
JohnWilson wrote:So xas is nothing to do with GPLed code? I tried building the binutils source in the GPL-compliance section of the XMOS web site and I get an apparently vanilla gas which doesn't seem to have heard of the XS1, but maybe I'm doing it wrong.
As far as I know, only "ar" from binutils is used (installed as "xmosar", "xar"
was already taken). It is built for i386-elf. That does not matter terribly much
for ar of course.
This would be a real shame if so though -- if the documentation is really complete then xas is a toy assembler, with no macros or irp or rept or even if/then (using the C preprocessor misses the point -- no looping or conditionals within macros or access to the assembler's symbol table)
Yeah, the GAS meta-constructs are an actual programming language, and the
C preprocessor is not (and that is totally ignoring the awkward syntax of the
latter). It's really nice to have it if you write bigger pieces of code in assembler.
... and it would be nice to be able to add that stuff (or enable it if already present) w/o having to write a new XS1 assembler from scratch.
Well, port binutils! Porting GAS isn't much work, assuming you already have
BFD... Which you don't.

Re: Documents detailing XTAG interface?

Posted: Mon Apr 30, 2012 7:14 pm
by JohnWilson
segher wrote:Well, port binutils! Porting GAS isn't much work, assuming you already have
BFD... Which you don't.
So close! :)

Re: Documents detailing XTAG interface?

Posted: Tue May 01, 2012 3:14 pm
by segher
[Whoops, I missed your post, how did I do that...]
LyleHaze wrote:Major edits as follows:
90% are in jtag.c, using simple #if defined() to remove buffering and adapt
my bit-banged code. I tried to keep it from getting too messy. You may or may not agree that I was successful.
I'm working on some stuff that will abstract the JTAG "adapter" stuff, so it should
be nicer after that. You'll see :-)
I created a separate makefile-amiga. I never learned how to do advanced (or even average) makefiles. I don't mind messing up MY copy as long as I can stay out of yours. If you want to fix mine up, feel free. :)
Do you use GNU make?
The only other edits were to handle compiler warnings about printing longs without an l qualifier on the conversion character.
Oh whoops. How did I do that?

Erm, I do not have a single long int in anything, it must be something you introduced :-)
There are two executables that I could not compile. "term", which I did not even try,
"term" is mainly to use the FTDI serial (on the second USB interface); using the
OS-provided serial driver is a huge hassle and very non-portable. It doesn't do
anything interesting otherwise.
and "runxe", which needs sys/mman.h. If I knew what it's needing, maybe I could come up with a replacement. So far I have not even looked.
mman.h is for mmap(), which i use to map the whole XE file into memory. You can
for example do fopen(), fseek(), ftell(), rewind(), malloc(), fread(), fclose() instead.
With error handling if you're a good boy. I like my mmap()s :-)
I have run each.. with a few surprises. all the regs variants show most or all zeros. a few regs have random values. The ID reg at the bottom increments from 0 to 7, this gives me some confidence that I'm reading data well.
That sounds good really.
I took a dump and a dump-rom.. I expected all 0 or all FF.. got weird repeating patterns instead.
Well the ROM isn't empty, and the RAM depends on what you ran on the chip of course.
Maybe my changes broke something? Would be happy to post or E-mail the output if you're interested in seeing it.
Yeah, mail me whatever you have please. Just message me on here.
Ran Resources for the first time this morning. There are the output regs I was looking for! Nice to almost recognize something.
"resources" outputs everything in a totally raw format. It's just so _much_ data, I
feel bad about doing anything more verbose :-)
Switching cores.. does not seem to be working for me. But since there's not much going on in the cores, how could I be sure? I assume just adding "-j 1" to the command line would (should) show the second core?
Yeah. I always write "-j1" but "-j 1" works just as well.
Also -l or --list shows nothing. Since I have no idea what I'm looking for, this is probably my own ignorance.
By "debug devices" are you listing USB based tools? I could understand why there would be none.
"-l" shows the JTAG adapters. "-c" shows the JTAG chain on one adapter, try
that one :-)

Have fun,


Segher

Re: Documents detailing XTAG interface?

Posted: Wed May 02, 2012 2:43 pm
by LyleHaze
segher wrote:
LyleHaze wrote:The only other edits were to handle compiler warnings about printing longs without an l qualifier on the conversion character.
Oh whoops. How did I do that?

Erm, I do not have a single long int in anything, it must be something you introduced :-)
I think it depends on what your definition of "long" is. (that's what SHE said! :lol: )

It's probably just my compiler being extra-picky. But to print a 32 it likes %ld instead of %d.
If that's my biggest problem today I'll call it a great day and move on.

I have more questions. I'm sure I'll need to switch over to the newbies forum soon, but since they will assume I'm using XDE and an XTAG adapter, I'll have a lot less to explain if I stay here for now.

I have the code that was run on this board for a previous demonstration. I have opened XDE and created a project, I can compile, and even edit sometimes, when I'm not in "Read Only" mode (the cause of which appears undocumented) :?

The program is a very simple LED flasher that flashes one pin on each of the two cores.
It compiles without error.

When manually creating the project, I had to select the core it would run on. There are FOUR different selections for XS1-L2.. What is the difference between those four selections, and which do I choose?

Is there some way to watch those two output pins in a simulator? I couldn't figure out how to get that working at all.

The comiled output looks like the *.xe file. But I am afraid to pass it to the run command because:
The program runs on both cores, and I don't know which one to load/run it on.
The run program has a maximum file size of 64K, and this .xe file is about 86 K in size.

So, best guess is that I need a different output format from XDE for using with your "Run" command.
If I need to compile from a command line, Great! If we ever port tools over that's where we will be working from anyway.

Any suggestions will be appreciated.

re: getting your code back.. I'm adding resource locking on the Amiga side, I'd like to get that in before the code leaves here, just to make sure no "rogue" Amiga apps are in the wild without it.
Yes, the user can always remove that code if they choose, but then any resource conflicts are their own fault. ;)

You should see the code in a few days or less.
Thank You!
Lyle