ESP8266 Community Forum

- Wed Apr 28, 2021 6:06 am #91246 Success!

The culprit appeared to be the config option for a "static link toolchain" which I enabled. This is quite logical for a bare metal target, but your config patch has a comment it doesn't always work, so I tried it without and that did the trick.

Next step is to find which of the options changes are really required to make the whole stuff work, additional to the ones already there in the Philipov repo and patch the config with it. I have some more specific options (like enabling floating point in newlib) that imho should not be in the generic config and I'll keep them in a local patch.

- Wed Apr 28, 2021 7:08 pm #91253 That's awesome!!! Well done

Have a look through the local patches in my file (the latest versions will be closest match to the code) and see if they still apply or not.

There are only newlib and gcc patches - nothing for any of the rest of the toolset. I assume this is because everything else either has no effect on the generated code, or is built using the patched gcc and newlib anyway.

Oh and one last thing - you will need to have a look at my instructions and strip the symbols defined in ROM from both libgcc and libc, otherwise the compiler will use the library based ones

export PATH=$(TOOLCHAIN)/bin:${PATH}
cd $(TOOLCHAIN)/lib/gcc/xtensa-lx106-elf/<version>
xtensa-lx106-elf-ar -M < strip_libc_funcs.txt
xtensa-lx106-elf-ar -M < strip_libgcc_funcs.txt

- Thu Apr 29, 2021 3:07 am #91256

Have a look through the local patches in my file (the latest versions will be closest match to the code) and see if they still apply or not.

The patches you apply are also in the fork by jcmvbkbc, which I used for rebasing my fork, so they're already in. Without them I would not have been able to succesfully build (a.o. missing newlib support for lx106).

Oh and one last thing - you will need to have a look at my instructions and strip the symbols defined in ROM from both libgcc and libc, otherwise the compiler will use the library based ones

export PATH=$(TOOLCHAIN)/bin:${PATH}
cd $(TOOLCHAIN)/lib/gcc/xtensa-lx106-elf/<version>
xtensa-lx106-elf-ar -M < strip_libc_funcs.txt
xtensa-lx106-elf-ar -M < strip_libgcc_funcs.txt

I actually never have done this. I assume it will save some disk space, but I don't think it's a requirement for succesful operation.

I think these lines in my load script already force the linker to use the rom based versions. I assume everybody does it, as it's also in the Espressif "eagle" linker scripts (included).

Code: Select all...
PROVIDE ( ets_memcpy = 0x400018b4 );
PROVIDE ( memcpy = 0x4000df48 );
...


Also gcc will mostly not even generate a call for memcpy (and some similar) functions, because it inserts small replacement code by itself (unless you specificly turn off that feature).

- Thu Apr 29, 2021 4:29 am #91258 Please try it! Also others. With this you get gcc 10.3 (and latest version of CT-ng).

https://github.com/eriksl/crosstool-NG

Just clone it and build as per ct-ng procedure.

I did some extra tweaks in newlib, to reduce code, stuff we shouldn't need on bare metal anyway, so I am curious if it has impact maybe for some of you.

If it turns out to be all okay, I will try to get upstream (CT-ng themselves) to adapt the changes, so we always have the latest gcc. Newlib will remain at v2.0.0 until someone does the work of patching the newer versions. I don't mind having v2 though.