ESP8266 Community Forum

The posted IoT SDK has been built with the proprietary Tensilica SDK which runs on Windows.
http://ip.cadence.com/support/sdk-evaluation-request

However, it is possible to build a custom GCC that can be used to program the chip. To do that someone has to get the "configuration overlay" from Espressif that they used to generate the processor for the ESP8266. That configuration overlay can then be used to generate a GCC that will work.

http://wiki.linux-xtensa.org/index.php/ ... erlay_File

It would also be helpful if they reworked their library to not call _xtos_set_exception_handler which is a proprietary Tensilica function and not really necessary for them to use.

Maybe some one fluent in Chinese can call them up and explain this to them. Once they understand they might start providing the needed gcc as part of their product offering.


On Sat, Aug 30, 2014 at 5:52 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> I'm looking for an open source (or redistributable) compiler for the
> Xtensa LX3. There is an SDK available for the chip here -
> http://www.seeedstudio.com/document/pdf ... k_v0.6.zip
> But I can't compile it since I don't have a compiler. I have no
> problem with the wifi support being a binary library, what I want to
> do is add my own application code..
>
> I've located this page about building compilers.
> http://wiki.linux-xtensa.org/index.php/ ... tributions
>
> But I haven't been able to work out exactly which compiler I should be
> building so that I can compile this SDK. We want a redistributable
> compiler so that others can also change the application code on the
> chip.

binutils+gcc is probably the only option here. I looked at the
object files in the SDK archive above and it appears that they
carry undefined references to xtos functions, which, AFAIK
you can get only with libraries from proprietary xtensa toolchain.
I.e. you won't be able to create a complete runnable image
even with properly configured binutils+gcc solely from the files
in that archive.

> I am trying to work with the chip vendor, Espressif, but there is a
> major language barrier and progress is slow.

They could provide the so called configuration overlay, having that
would allow building binutils that support all instructions available
in the processor and gcc that can employ all of its standard
features.

> From the binaries in the SDK...
>
> #Xtensa Compiler Version 8.0.1 : udp.c compiled with : -O2 -g3
> Xtensa_Info
> HW_CONFIGID0=0xc28cdafa
> HW_CONFIGID1=0x1082b6f6
> BUILD_UNIQUE_ID=0x0002b6f6
> ABI=1
> USE_ABSOLUTE_LITERALS=0
> HW_VERSION="LX3.0.1"
> HW_MIN_VERSION_MAJOR=2300
> HW_MIN_VERSION_MINOR=1
> HW_MAX_VERSION_MAJOR=2300
> HW_MAX_VERSION_MINOR=1
> RELEASE_NAME="RC-2010.1"
> RELEASE_VERSION="8.0.1"
> RELEASE_MAJOR=8000
> RELEASE_MINOR=1
> CORE_NAME="lx106"

In addition the object files are little endian. The above information
is not sufficient for building a compiler, because each possible
standard feature of xtensa processor may be controlled independently.
The complete set of files that describe configuration is generated with
the processor itself. Normally to build xtensa binutils+gcc for a given
core one can take the mainline binutils and gcc and replace xtensa
configuration files with ones specific for the processor core. E.g.
buildroot can build such customized toolchain.

In the situation when the exact configuration is unavailable a possible
strategy is to take some configuration with the same endianness and
disable features in it manually. Then gcc won't use the instructions
from the disabled features. See XCHAL_HAVE_* macros in
{binutils,gcc}/include/xtensa-config.h files.

A small collection of xtensa overlays is available here:
https://github.com/jcmvbkbc/xtensa-tool ... r/overlays

First: thanks for this (so far) comprehensive write-up.

jonsmirl wrote:It would also be helpful if they reworked their library to not call _xtos_set_exception_handler which is a proprietary Tensilica function and not really necessary for them to use.

Still, _xtos_set_exception_handler is far from rocket science to replicate (or replace with a stub). I figure the problem is that the library depends on the effects of this function (namely, registering an exception handler for a given exception cause)?
We have the sources for proprietary functions like this one, although I guess we are legally not allowed to use those.

I looked at the
object files in the SDK archive above and it appears that they
carry undefined references to xtos functions, which, AFAIK
you can get only with libraries from proprietary xtensa toolchain.
I.e. you won't be able to create a complete runnable image
even with properly configured binutils+gcc solely from the files
in that archive.

The binary representations of said functions can possibly be extracted from the firmware / ROM once someone finally receives a board (and manages to extract the firmware), since we know where in the firmware said functionality resides. That extraction may however prove to be hard to do.

They could provide the so called configuration overlay, having that
would allow building binutils that support all instructions available
in the processor and gcc that can employ all of its standard
features.

In the meantime, we will have to assume the processor only contains the basic functions and work our way up from there.

[...] See XCHAL_HAVE_* macros in
{binutils,gcc}/include/xtensa-config.h files.

Since the libraries call _xtos_set_exception_handler, we know that XCHAL_HAVE_EXCEPTIONS is set. Floating-point related XCHAL_* macros can for example be derived once we have an actual ROM binary, comparing it to the contents of ieee754-df.S (which we also have but are most likely not able to use legally).

I'd also like to point out that the CORE_NAME (as found in the libraries) is lx106, and we HAVE an overlay with the same name (in the virtual machine image, C:/usr/xtensa/XtDevTools/install/builds/RC-2010.1-win32/lx106/src/xtensa-config-overlay.tar.gz), and the correct release (obviously RC-2010.1) and release version (8.0.1), AND the correct HW_CONFIGID0 and HW_CONFIGID1.

Seems like we have the overlay readily available? (although we are, again legally, likely unable to really use it if anyone is watching us ).

Edit: heck, it even has the correct XCHAL_BUILD_UNIQUE_ID. If that's truly a unique ID, this means we have the overlay. Hurray!

Yes, the overlay was in the VMWare image. These instructions allow the compiler to be built.
http://wiki.linux-xtensa.org/index.php/Crosstool-NG

You should be able to build and link except for: _xtos_set_exception_handler
We will need to figure out how to write a replacement.

So next step is to rework the makefiles to run under Linux.