ESP8266 Community Forum

- Tue Oct 11, 2016 5:59 pm #56393

SDK name and URL are outside the crosstool-NG realm, but I can apply the cygwin64-specific patch.

Ah of course - those are esp-open-sdk issues, aren't they? Will let them know. BTW my latest fiddling has shown that the cygwin64 bug only affects gcc 4.8.5. gcc 5.2.0 works fine out of the box with a 64 bit build environment - they had added very similar patches to what I sent.

My current crosstool-NG? I believe my xtensa-1.22.x branch is a couple of patches ahead of what open-esp-sdk refers to, but they are not significant. You should be able to update to the latest crosstool-NG in the open-esp-sdk and it should just work.

I ended up checking the commits and finding just one change that added a patch, so I cheated and just manually copied it in.

Right now I have a tool chain that compiles nicely from both Windows and cygwin command lines, and works beautifully with an Eclipse based Makefile project, but I have a couple of really annoying issues:

- cygwin maps all Windows drives to /cygdrive/* in order to implement a Unix like file system. Cygwin's make uses this mapping, and the command line tools all do neat translations between Windows C:\ and cygwin /cygdrive/c/ etc. However, the CDT Discovery feature in Eclipse on Windows doesn't do this mapping for a GCC Cross project and so all the include and lib directories are screwed up, which then messes up the C code editors and checkers. The dumb thing is that they have a section in the gdb settings to create path maps so that gdb can find the code on Windows drives!

At this point in time it looks like the only solution to get the editor working is to clear the auto discovery paths and then manually add them all back using windows path format. However this will break the Makefile generation capability, but since I tend to create my own from a template I guess that's not too awful. I just wish Eclipse had this fixed!!

- the default linker ld mapping files are all for early devices and there doesn't seem to be any for ESP12E or F based devices that have 4M flash. I'm currently trawling through posts looking for suitable *.ld files, or for what changes I need to make to the current ones to make them give me the correct memory settings and sizes.

- esptool.py is currently not producing the correct named files for the example blinky project. I wonder if it's related to the *.ld files above, but right now the example Makefile names are inconsistent with the output and instead of getting blinky-0x40000.bin I get blinky-0x10000.bin. In addition I am once again fighting Windows vs cygwin naming and can't work out how to correctly reference the USB COM port where the ESP8266 is attached. Thinking I may go to the .exe version from the Espressif site

- Thu Oct 27, 2016 11:25 pm #57259 So I've been very happily flashing chips with some of the demo samples and for the most part getting them to work but one thing that's been a bit weird is the memory layout of the flash and the settings reported by the API functions.

I have an ESP12E 4M chip that I'm using (actually it's a Node MCU V3 - the Lolin model) and I'm flashing it using 1024+1024, which on the espflash command line is mode 6. But the API seems to report the chip is running in mode 4, which is 512+512. I'm still trying to work out how I can get as much programmatic storage as possible as I don't use SPIFFS for much, and I need to fit a fair amount of code.

I also pulled the very latest changes from all the different crosstool-ng projects and rebuilt the toolchain firstly using gcc5.2.0 and then gcc5.4.0, and once again everything seemed to be ok, but I was missing some of the newly added implementations of standard functions, which was weird and got me investigating, and that's when I opened a whole can of worms.

It appears the SDK ships with its own libgcc.a in the /lib directory, and in both the esp-open-sdk STANDALONE=y as well as the separate SDK STANDALONE=n builds, its position in the directory structure masks the libgcc.a that gets built as a result of compiling crosstool-ng. The one in the SDK is about 500k in size and the one that gets built is about 750k so there's a big size difference.

But that's not all. When I renamed the libgcc.a provided in the SDK, all my programs threw errors because .text was too large to fit in iram. So for some reason the provided library's .text fits, but the compiled library's .text doesn't

I went through the build logs and the switches I used to compile were -O2 -Os and no debug symbols are included, so now I wonder how long the SDK provided libgcc has been masking this issue.

Anybody have any ideas for me to try?

- Fri Oct 28, 2016 9:11 pm #57318

now I wonder how long the SDK provided libgcc has been masking this issue.

It appeared in SDK-1.5.3.

The one in the SDK is about 500k in size and the one that gets built is about 750k so there's a big size difference. But that's not all. When I renamed the libgcc.a provided in the SDK, all my programs threw errors because .text was too large to fit in iram. So for some reason the provided library's .text fits, but the compiled library's .text doesn't

Looks like there are less files in the SDK version of libgcc than in the version built by the esp-open-sdk, the remaining functions must come from the ROM. You can check what comes from where by adding -Wl,-M to your linker options and seeing what object files are pulled in.

And if you look inside the object files from libgcc.a from the SDK you'd find strings like this:
/home/wjg/Repo/esp-open-sdk/crosstool-NG/.build/src/gcc-4.8.2/libgcc/
so this is just esp-open-sdk with some older crosstool-NG. I guess Espressif added patch for gcc that stops building libgcc components that are already in the ROM.

- Sat Oct 29, 2016 1:03 am #57323

now I wonder how long the SDK provided libgcc has been masking this issue.

It appeared in SDK-1.5.3.

The one in the SDK is about 500k in size and the one that gets built is about 750k so there's a big size difference. But that's not all. When I renamed the libgcc.a provided in the SDK, all my programs threw errors because .text was too large to fit in iram. So for some reason the provided library's .text fits, but the compiled library's .text doesn't

Looks like there are less files in the SDK version of libgcc than in the version built by the esp-open-sdk, the remaining functions must come from the ROM. You can check what comes from where by adding -Wl,-M to your linker options and seeing what object files are pulled in.

And if you look inside the object files from libgcc.a from the SDK you'd find strings like this:
/home/wjg/Repo/esp-open-sdk/crosstool-NG/.build/src/gcc-4.8.2/libgcc/
so this is just esp-open-sdk with some older crosstool-NG. I guess Espressif added patch for gcc that stops building libgcc components that are already in the ROM.

Thanks for the reply!

So what you're saying is that the linker is pulling in all the functions already in ROM and that's why it's too big? Is there any way we can strip these out from libgcc as part of the crosstool-ng build? Or any other steps we can take so we can use the built version?

I am assuming it's better to use a libgcc built with newer gcc versions because there may be some optimisations added?