.xe header change with XTimeComposer 12.2

[LyleHaze]

Hi,
I am from a group who have XS1-L2 processors embedded on our PowerPC motherboards...
Because the XDE tools cannot run under PowerPC, we have to compile on X86 machines and then move the resulting .xe files over by flash drive or FTP for loading into the XMOS chip.

As a result, two major differences when we build projects:
1> when we edit and build the project, there is NO jtag interaction with the target chip.
2> Once the code is moved over to the target platform, we use an onboard PGA for the JTAG connection, along with a set of utilities that have been ported to PPC for us to use.

So far, it has worked as well as we can hope for non-native compiling. But with the latest release of XTimeComposer, there has been a change in the file header of *.xe files. These are no longer accepted by RunXE, and we are in a position of either modifying our tools or abandoning all future advances in your compiler suite.

So the questions: How can get detailed information on what has changed in the .xe file format for 12.2, and what I will need to adapt to remain compatible?
And since I'm asking anyway, what are the options for a PowerPC build of your compiler and tools? We number in the hundreds and still growing, though many are waiting for compiler tools that can run native on our systems. Even basic command line compiler and linker would be a huge step forward from our current cross-compiling situation.

Thank You,
Lyle

[richard]

So the questions: How can get detailed information on what has changed in the .xe file format for 12.2, and what I will need to adapt to remain compatible?

The changes are as follows:

• The ELF e_machine field has changed. We were using a temporary number previously but we've now been assigned a official number (203). The list of e_machine values can be found here: http://www.sco.com/developers/gabi/late ... eader.html
• We fixed an issue with the CRC calculation for XE sectors. It didn't match the documentation before, now it does.
• The major version of the XE has been bumped from 1 to 2 due to the incompatible sector CRCs

It appears that The Tools Developer guide hasn't yet been updated with these changes, I'll ask about this.

Are you using Segher's runxe.c? (http://git.infradead.org/users/segher/d ... 3:/runxe.c). I had I brief look at the code. I think only two changes are necessary - line 59 needs to be updated to accept the new ELF e_machine number and line 228 needs to be updated to accept the new XE major version.

And since I'm asking anyway, what are the options for a PowerPC build of your compiler and tools? We number in the hundreds and still growing, though many are waiting for compiler tools that can run native on our systems. Even basic command line compiler and linker would be a huge step forward from our current cross-compiling situation.

You should be able to build the C compiler from the source we provide (http://www.xmos.com/products/design-tools-source). However the source of the XC compiler frontend / assembler / linker is not available. Is it feasible to run these binaries using emulation (e.g. qemu user mode emulation?). If not then you'll need to provide an alternative assembler / linker. My understanding is that Segher is working on an xCORE binutils port (http://www.xcore.com/projects/binutils-xs1). Alternatively the LLVM MC project might be of interest (http://blog.llvm.org/2010/04/intro-to-l ... oject.html), although this would need some work (there is currently no xCORE assembly parser).

[pstnotpd]

I am from a group who have XS1-L2 processors embedded on our PowerPC motherboards...

Is this, by any chance, the X1000?

[Folknology]

I have a similar problem on ARM platforms, I cannot use the Xmos toolset/chain directly. So again if any changes are planned it would be nice to be able to run the toolset on Arm as well as PowerPC. I do not know why Xmos haven't open sourced the XC side of the toolchain, they have certainly indicated this to be a goal in previous communications. Opensouring this part of the chain may well aide the porting of these tools, by leveraging the community.

regards
Al

[LyleHaze]

Richard,
Thank You!
A bit of knowledge helps, better than crashing forward and wondering what I might have missed.

pstnotpd,
Yes, it might be the X1000.. awesome machine, great OS too!

Folknology,
Support across a variety of platforms could only be good.. at least it looks better than it did even ten years ago. Nowadays it is apparent that the mobile segment is growing, and that is NOT completely locked down by MS and windows. Hopefully the trend away from MS as the "only OS to be supported" will continue... hopefully.
Until then I'll rely on FTP and a series of build scripts to get the job done.
It may be ugly, but at least I don't have to physically swap computers every time I want to build.

Thanks all for the support and quick answers!

[segher]

The changes are as follows:

Thanks for the info! I hadn't noticed anything changed since I still use 11.x :-)

I'll get this updated in runxe and binutils ASAP. Can someone provide me with
a binary generated by the new toolchain? Maybe something that runs on a slicekit?

We fixed an issue with the CRC calculation for XE sectors. It didn't match the documentation before, now it does.

Did you change the documentation so v1 is now the "bad" algorithm?

Are you using Segher's runxe.c? (http://git.infradead.org/users/segher/d ... 3:/runxe.c). I had I brief look at the code. I think only two changes are necessary - line 59 needs to be updated to accept the new ELF e_machine number and line 228 needs to be updated to accept the new XE major version.

Yeah, I don't check that CRC :-)

My understanding is that Segher is working on an xCORE binutils port (http://www.xcore.com/projects/binutils-xs1).

It is completely usable, and has been for a long time. But please note it does not
handle any of the XC-specific stuff, nor e.g. the "C" flag on sections ("addressed via
the CP register"); you are expected to handle that the normal way (via a linker script),
not with very intrusive toolchain hacks. I doubt I will ever be able to get the weird
things into upstream binutils ;-) Simple linker scripts work just fine for even the
most complex programs I have tested (which aren't XC, of course, but mostly plain
C and C++ (ugh) and assembler).

It is probably easy to link object files generated by the XMOS tools using my binutils
port. I do not currently provide startup code for more than one core, but it's easy
to write your own, certainly for Xena.

[richard]

The changes are as follows:

Thanks for the info! I hadn't noticed anything changed since I still use 11.x :-)

I'll get this updated in runxe and binutils ASAP. Can someone provide me with
a binary generated by the new toolchain? Maybe something that runs on a slicekit?

We fixed an issue with the CRC calculation for XE sectors. It didn't match the documentation before, now it does.

Did you change the documentation so v1 is now the "bad" algorithm?

The documentation hasn't changed - there was a bug in the implementation. We didn't spot it for a while because the code that checked the checksum was the same code that generated it. We decided to fix the code rather than document the incorrect version of CRC we had as we were already making other changes that would affect backwards compatibility between 11.11 and 12.0 (e.g. changes in the .xn file embedded in the XE).

It is completely usable, and has been for a long time. But please note it does not
handle any of the XC-specific stuff, nor e.g. the "C" flag on sections ("addressed via
the CP register"); you are expected to handle that the normal way (via a linker script),
not with very intrusive toolchain hacks. I doubt I will ever be able to get the weird
things into upstream binutils ;-)

Does that mean you are planning to submit your changes back upstream?

[segher]

Did you change the documentation so v1 is now the "bad" algorithm?

The documentation hasn't changed - there was a bug in the implementation.

Sorry, that wasn't well phrased. I understand the implementation wasn't what
was designed. But now you have a file format v2 that _is_ the original design,
and a v1 that uses some other CRC algo. It would be nice if v1 was also documented
(or simply "do not check the CRC for v1" will do, I suppose :-) )

We didn't spot it for a while because the code that checked the checksum was the same code that generated it.

Heh.

We decided to fix the code rather than document the incorrect version of CRC we had as we were already making other changes that would affect backwards compatibility between 11.11 and 12.0 (e.g. changes in the .xn file embedded in the XE).

That's one of the reasons why I'm still on 11.x, yeah. Stupid newspeak that
requires me to change all my old code.

Does that mean you are planning to submit your changes back upstream?

Yes, of course, I thought that was clear :-)

I'm not sure exactly when yet, but "soon".

[richard]

Sorry, that wasn't well phrased. I understand the implementation wasn't what
was designed. But now you have a file format v2 that _is_ the original design,
and a v1 that uses some other CRC algo. It would be nice if v1 was also documented
(or simply "do not check the CRC for v1" will do, I suppose :-) )

If you want to use the v1 format my recommendation would be to not check the CRC (if you are reading) and set the field to 0 which disables CRC checking (if you are writing). A description of the actual v1 algorithm is as follows:

• Initialize CRC register with 0
• Compute the CRC over the sector (including header and padding) with a polynomial of 0xEDB88320 (this is not the standard ethernet CRC, it is the bit reverse of it). Unlike a normal CRC the input should not be left padded with 32 zeros (i.e. you don't have final CRC step with a zero word).
• If both the MSB of the result and the MSB of the last byte of data differ then XOR with 0xEDB88320
• Bit reverse the result

[LyleHaze]

Thanks go out to richard and segher.
Our tools are now working fine with both older and the current XDE.

folknology: It seems we would both like to see the toolchain available on
more platforms than it is now. I have a unique idea, but I'll start a new thread
to suggest it. :)