Error in creating ESP8266 Firmware

Today I downloaded actual version from github.
Looks like there are some major changes, sources for Math-functions disappeared.
Running make (ESP8266_BOARD=1 make) now returns this error:

LD espruino_esp8266_user1.elf
LD espruino_esp8266_user2.elf
/home/espruino/git/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld: espruino_esp8266_user2.elf section .text' will not fit in regioniram1_0_seg'
collect2: error: ld returned 1 exit status

Is there anything else I have to do like new SDK or something like that ?

Just checked, and as you suggest, it's this commit: https://github.com/espruino/Espruino/commit/9781bacee8185b58438604cb22672389bc3ff42d

Extremely frustrating as the 'built-in' maths functions that were removed were pretty bad, and doing the removal has actually improved the situation on pretty much all platforms.

@tve do you have any ideas how this could be fixed? I increased the size of iram1_0_seg in the linker so it builds, then grabbed these out of the listing:

40107778 g     F .text	00000002 rcUpdateDataRxDone
40102970 g     F .text	00000007 __errno
40102850 g     F .text	00000007 nan
40105300 g     F .text	0000000b phy_get_mactime
40102978 g     F .text	0000000f srand
40104258 g     F .text	00000010 ets_timer_setfn
40102840 g     F .text	00000010 finite
40102934 g     F .text	00000011 copysign
40102948 g     F .text	00000013 atoi
40109970 g     F .text	00000018 strchr
40104550 g     F .text	0000001b xPortWantedSizeAlign
40108600 g     F .text	0000001e wDev_DisableTransmit
40104460 g     F .text	0000001f prvInsertBlockIntoUsedList
40104134 l     F .text	00000020 dhcp_timer_fine
40104184 l     F .text	00000020 dns_timer
40108668 g     F .text	00000023 wDev_ProcessCollision
40104104 l     F .text	00000026 dhcp_timer_coarse
40104524 g     F .text	00000029 prvRemoveBlockFromUsedList
40105470 g     F .text	0000002b clockgate_watchdog
40104698 g     F .text	0000002e pvPortCalloc
40109988 g     F .text	0000002f strncat
40100588 g     F .text	00000034 .hidden jslIsToken$1409$constprop$21
40100094 g     F .text	00000035 jshGetSystemTime
40103890 g     F .text	00000036 .hidden __muldi3
40107444 g     F .text	0000003a RC_GetBlockAckTime
40104780 g     F .text	0000003b Cache_Read_Disable_2
40102988 g     F .text	0000003b rand
40108620 g     F .text	00000045 Tx_Copy2Queue
40106754 g     F .text	00000048 lmacProcessCtsTimeout
40109920 g     F .text	00000050 memset
40104640 g     F .text	00000051 vPortFree
40104964 g     F .text	00000055 spi_flash_read
40108720 g     F .text	00000058 wDev_SetFrameAckType
40105340 g     F .text	00000061 phy_get_bb_freqoffset
40106268 g     F .text	00000067 lmacProcessTxTimeout
40106898 g     F .text	0000007f lmacProcessTxError
40106344 g     F .text	00000081 lmacProcessCollision
40100114 g     F .text	00000084 jshPushIOEvent
40104498 g     F .text	0000008b pvShowMalloc
40104498 g     F .text	0000008b system_show_malloc
40107688 g     F .text	00000093 rcUpdateTxDone
40107878 g     F .text	00000099 rcGetRate
40104578 g     F .text	000000c3 pvPortMalloc
40102858 g     F .text	000000dc scalbn
40107794 g     F .text	000000df rcGetSched
40104368 g     F .text	000000f3 ets_timer_arm_new
40101048 g     F .text	000000f7 log
40106920 g     F .text	00000130 lmacTxFrame
40108784 g     F .text	00000142 wDev_AppendRxBlocks
40101140 g     F .text	000001cc __ieee754_atan2
40109430 g     F .text	0000033a .hidden __umoddi3
40101980 g     F .text	000003e0 __ieee754_rem_pio2

So it looks like the 3 biggest functions are maths ones, which potentially could be excluded from iram (somehow??).

Googling it seems to be a common ESP8266 issue (maths functions all going into RAM) but I'm not quite sure what can be done about that. There was some suggestion that the new SDK fixed it.

Potentially I could pull all the maths functions back in, but that's really nasty. When this gets fixed the current solution will be much better.

there is an ESP8266 lib for RTOS available working in irom instead of iram
https://github.com/espressif/ESP8266_RTOS_SDK/blob/master/lib/libmirom.a
A quick test replacing actual LIBS definition runs fine.

######LIBS=-lm # Maths
LIBS=-lmirom

At least Math.sin returns correct value.
Looks strange to me to take a lib from somewhere else, more like trial and error, therefore would be fine, if somebody with knowledge around this could check.

Thanks!

Looks strange to me to take a lib from somewhere else

Yes, absolutely! Thanks for finding it though - hopefully someone can shed light on this and I can add it to the build instead.

So when build errors occurs, is the travis builds the best place to find out what changes have occured?

https://travis-ci.org/espruino/Espruino/builds

Last working:

#1570 passed

master update sourcecode docs for analog - fix #808 avatar Gordon Williams

https://travis-ci.org/espruino/Espruino/builds/113648205

#1571 failed
https://travis-ci.org/espruino/Espruino/builds/113648205

Remove Espruino's built-in strcpy/etc Remove Espruino's built-in maths
Add basic Taylor series sin and atan for when we're trying to save memory

Yes, if you can't build yourself (and use git bisect) then Travis is a good plan.

Actually that reminds me - if we just turned on the taylor series sin, that would probably fix it... But using the 'proper' maths libraries has got to be better.

Ok, have just changed it to use libmirom, so it should build again now: https://github.com/espruino/Espruino/commit/ada53500e41ec4deebb469d304c06adad34307d2

We can always roll it back if it turns out there is some problem.

Thanks. So there there is a new lib dependency to download and install, or is this in the 1.5 package already? I noticed that @jumjum 's reference above was for a 1.4 library..

Oh - I see you have added- targets/esp8266/libmirom.a.

Yeah, it's a bit nasty - but maybe if/when it gets ported to 1.5 then the library can get removed

Hey, there is one great side effect here, that is the image size is soooo much smaller:

-rw-r--r-- root/root 462244 2016-01-08 16:01 ./espruino_1v84.48_esp8266/espruino_esp8266_user1.bin

After a git pull with the linked mathlib:

-rw-r--r-- 1 root root 437812 Mar 11 07:36 espruino_esp8266_user1.bin
So I though there would be space for the graphics lib:

root@esp8266-VirtualBox:/home/esp8266/Espruino# cat ./build-graphics.sh

 #! /bin/bash
export ESP8266_BOARD=1
export FLASH_4MB=1
export USE_GRAPHICS=1
export ESP8266_SDK_ROOT=/home/esp8266/Espruino/esp_iot_sdk_v1.5.0
export PATH=/home/esp8266/esp-open-sdk/xtensa-lx106-elf/bin:$PATH
export COMPORT=/dev/ttyUSB0
make $*

-rw-r--r-- 1 root root 454596 Mar 11 07:41 espruino_esp8266_user1.bin

I've not yet tested this binary, however it looks really promising!
@MaBe - not sure if we need to reduce the # of vars

Add in USE_CRYPTO=1, the build fails due to:

/home/esp8266/esp-open-sdk/xtensa-lx106-elf/lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld: address 0x3fffca00 of espruino_esp8266_user2.elf section `.bss' is not within region `dram0_0_seg'

So I still need to try to reduce the size to get the SHA1 function for use in web sockets.

@Wilberforce: the force that pushes the 8266 envelope!

Great! I did a bit of work to make some of the less-used trig functions out of other ones, which seems to cut down on usage quite a bit...

Good news about the Graphics lib - I think it's actually the RAM usage rather than ROM that causes the biggest problems with stuff like Graphics though. @MaBe had done some work on trying to move that into ROM but I'm not sure he had much luck.

@Wilberforce, sure you can build without errors, but flashing with that image will permanently resting the ESP, just tested with 1v85

@Gordon now I have again time to continue testing with fonts in ROM