ESP8266 Community Forum

- Wed Oct 01, 2014 9:19 am #1079 jcmvbkbc,
Thank you very much your effort in making gcc successful for this CPU.

Looks like you've used stock gcc-4.9.1, not the patched version that has WIP-support for call0 ABI from here: https://github.com/jcmvbkbc/gcc-xtensa/ ... all0-4.8.2

I am little new to this cross compile, how can I take the patches from 4 patches from 15th Sep'14 (3 patches) and 1 patch (on 29th Sep'14) and apply those patches.

Thanks for the help

mahadevan

- Wed Oct 01, 2014 11:27 am #1081

how can I take the patches from 4 patches from 15th Sep'14 (3 patches) and 1 patch (on 29th Sep'14) and apply those patches.

Several options here, depending on what you have locally and whether you're interested in the compiler source itself:
1) if you want to just build that thing and you have no gcc-4.8.2 sources already the easiest thing is to download the snapshot archive through the 'Download ZIP' button at that page: https://github.com/jcmvbkbc/gcc-xtensa

2) if you have gcc-4.8.2 sources locally and want to patch it with call0 patches then you can download cumulative patch from https://github.com/jcmvbkbc/gcc-xtensa/ ... .8.2.patch and apply it locally with patch utility

3) if you're a developer and have gcc git tree locally you can
git clone --refer <your existing tree> git://github.com/jcmvbkbc/gcc-xtensa.git
and it will make a clone of my tree, but download only parts missing in your existing tree, presumably those four patches. You will be able to receive further updates into that tree with git pull.

4) you can always do a full git tree clone:
git clone git://github.com/jcmvbkbc/gcc-xtensa.git
it will take some time though.

- Wed Oct 01, 2014 11:55 am #1083 jcmvbkbc,

Thanks for the reply.

I have downloaded all tar.bz2 for the versions mentioned in prepare.sh and config.
I have following directory structure after extracting (and partial build with manual overwriting of 5 latest files that are modified in your patches)
[gssm@apu1 gcc-xtensa]$ ls -ltr /src/rd/xtensa-toolchain-build-master/ |grep ^d
drwxr-xr-x 34 gssm gssm 4096 Jul 16 16:44 gcc-4.9.1
drwxrwxr-x 3 gssm gssm 4096 Oct 1 00:46 patches
drwxrwxr-x 2 gssm gssm 4096 Oct 1 12:04 overlays
drwxrwxr-x 17 gssm gssm 4096 Oct 1 12:26 binutils-2.24
drwxrwxr-x 15 gssm gssm 4096 Oct 1 12:26 gdb-7.6
drwxrwxr-x 5 gssm gssm 4096 Oct 1 12:57 build-lx106

Here I have some build failures.

4) you can always do a full git tree clone:
git clone git://github.com/jcmvbkbc/gcc-xtensa.git
it will take some time though.

OTOH, I have already cloned this tree, but as prepare.sh does refer the .tar.bz2 . So I did not proceed with this tree, as I am not sure how to run prepare.sh/etc

- Wed Oct 01, 2014 12:00 pm #1084 OK, here is a slightly more detailed explanation of what i did to get the GCC compiled, and subsequently compile the AT firmware.
Keep in mind that i work on Linux, i have no idea what prerequistes are needed to get it to compile on Windows, sorry.

First you need get two ZIP files. The first contain jcmvbkbc's fantastic build scripts:
https://github.com/jcmvbkbc/xtensa-toolchain-build

Then the GCC 4.8.1 ZIP that jcmvbkbc worked on to make it usable for the lx106 core:
https://github.com/jcmvbkbc/gcc-xtensa

(On both pages there is a "Download ZIP" button to get the archives)

Now grab binutils-2.24 from here:
http://ftp.gnu.org/gnu/binutils/

Then gdb-7.6 from here:
http://ftp.gnu.org/gnu/gdb/

And finally newlib-2.0.0 from here:
http://ftp.gwdg.de/pub/linux/sources.redhat.com/newlib/

(Not sure if that one is really required, but i dl'd it anyways)

OK, now you extract "xtensa-toolchain-build-master.tgz" first. This will create a directory "xtensa-toolchain-build-master" with a bunch of stuff in it. In that buil-directory you now extract the remaining archives. Next you edit the "config" file in there. Comment out (or delete" the line "GCC=gcc-4.9.1", and instead put in a line "GCC=gcc-xtensa-call0-4.8.2".

You may need to edit the variable called "PARALLEL" in there as well, in case you have less or more than 4 processor cores on your host machine.

Next you run "./prepare.sh lx106". This should finish very quickly and report no errors. Once that is done, you run "./build-elf.sh lx106" (EDIT: corrected this one, i forgot to mention the lx106 parameter) which will actually build the toolchain. It may be that it will complain and stop with an error if you have some required lib or -dev packages missing. For example, i had the libmsp-dev package missing, which i then installed through the package manager (apt-get in my case), and then re-run "./build-elf.sh lx106".

It will take a while to compile. Once it is through you are almost there to compile stuff for the ESP8266. I assume you have any of the leaked SDK and the AT firmware sources, those are needed now. First you need to copy two libs from the original toolchain into the SDK's lib directory. These two files are libc and libhal. In the original VM they are in:

XtDevTools/install/builds/RC-2010.1-win32/lx106/xtensa-elf/lib/libc.a
XtDevTools/install/builds/RC-2010.1-win32/lx106/xtensa-elf/arch/lib/libhal.a

Note: I will attach those two files to this post. The reason is simple: In the original VM you will also find the sources to them. Not only that, but they havee a permissive license, that is, one can freely do with them what she/he wants. So i can't see any problem attaching the precompiled binaries here.

Alright, now you have the two extra libs, next step is to edit my Makefile so that it uses the freshly compiled GCC, and also to have it point to the systems include directory, since some sources use things like "#include <string.h>". I attach a modified Makefile here, just edit the path's to the new GCC tools accordingly.

Now that this is done, you can run "make" in the AT firmware directory, assuming it's file/directory layout is adapted to my makefile, but this will throw up an error, telling you that "uint32_t" is redefined. The original SDK defines it in "c_types.h", but some sources also include <stdlib.h> where at some point it will reappear. Simple fix is to just comment out all references to stdlib.h whereever it complains about this.

Finally you should end up with a error free make process for the AT firmware. You will also need my esptool and have it compiled for linux. At the top of the Makefile for it just replace the "TARGET_ARCH = WINDOWS" with "TARGET_ARCH = LINUX", that's it. Run make and copy the resulting executable to whereever you need it according to you firmware Makefile.

Adter all this you should end up with the two .bin files that you can then upload to the flash on the module. Right now i still use the esptool.py, but i'm halfway through implementing that functionality in my tool as well (just had to stop for a while due to a customer project i had to work on).

I hope that this clears up a few things.

Here is the archive with the extra two libs:

extra_libs.tgz

And here a modified Makefile, you still need to edit it to reflect your setup:

Makefile.tgz

I will try to get the sources for the two extra libs to compile with this GCC if i have time, so that we can have a "clean" source-tree for those two as well. But feel free to look into that as well, if you like to. I certainly won't mind.

Again, many thanks to jcmvbkbc for his fantastic work on the build-scripts as well as the coompiler modifications!

Enjoy, and Greetings,

Chris

EDIT: Sorry, messed up the files while i was trying to re-upload the Makefile (had a wrong one in there). Fixed now.

You do not have the required permissions to view the files attached to this post.

Last edited by mamalala on Wed Oct 01, 2014 12:32 pm, edited 1 time in total.