search

nodemcu / nodemcu-firmware

Lua based interactive firmware for ESP8266, ESP8285 and ESP32
https://nodemcu.readthedocs.io
MIT License
7.65k stars 3.12k forks source link

make fails due to python depreciation message #2599

Closed LongnoseRob closed 5 years ago

LongnoseRob commented 5 years ago

Expected behavior

checked out nodemcu/firmware as described in the documenation for a native linux buiid after running make I was expecting a file to be able to flash with esptool

Actual behavior

when running make it builds very nicely all the required files until I receive the following error:

xtensa-lx106-elf-ar: creating .output/eagle/debug/lib/libucglib.a
make[2]: Leaving directory '/home/robby/builds/nodemcu-firmware/app/ucglib'
xtensa-lx106-elf-gcc -L/home/robby/builds/nodemcu-firmware/sdk/esp_iot_sdk_v2.2.1/lib -L/home/robby/builds/nodemcu-firmware/sdk/esp_iot_sdk_v2.2.1/ld  -Wl,--gc-sections -Wl,-Map=mapfile -nostdlib -T../ld/nodemcu.ld -Wl,@../ld/defsym.rom -Wl,--no-check-sections -Wl,--wrap=_xtos_set_exception_handler -Wl,-static -u BIT_module_selected -u UART_module_selected -u I2C_module_selected -u U8G2_module_selected -u NET_module_selected -u NODE_module_selected -u FILE_module_selected -u GPIO_module_selected -u TMR_module_selected -u WIFI_module_selected -u SPI_module_selected -u ADC_module_selected -u UCG_module_selected -u OW_module_selected -Wl,--start-group -lmain -lc -lgcc -lhal -lphy -lpp -lnet80211 -lwpa -lwpa2 -lsmartconfig -lcrypto -lwps user/.output/eagle/debug/lib/libuser.a crypto/.output/eagle/debug/lib/libcrypto.a driver/.output/eagle/debug/lib/libdriver.a platform/.output/eagle/debug/lib/libplatform.a task/.output/eagle/debug/lib/libtask.a libc/.output/eagle/debug/lib/liblibc.a lua/.output/eagle/debug/lib/liblua.a lwip/.output/eagle/debug/lib/liblwip.a smart/.output/eagle/debug/lib/smart.a spiffs/.output/eagle/debug/lib/spiffs.a fatfs/.output/eagle/debug/lib/libfatfs.a pm/.output/eagle/debug/lib/libpm.a esp-gdbstub/.output/eagle/debug/lib/libgdbstub.a net/.output/eagle/debug/lib/libnodemcu_net.a mbedtls/.output/eagle/debug/lib/libmbedtls.a modules/.output/eagle/debug/lib/libmodules.a smart/.output/eagle/debug/lib/smart.a uzlib/.output/eagle/debug/lib/libuzlib.a u8g2lib/.output/eagle/debug/lib/libu8g2lib.a ucglib/.output/eagle/debug/lib/libucglib.a -Wl,--end-group -lm -o .output/eagle/debug/image/eagle.app.v6.out
./tools/esptool.py elf2image --flash_mode dio --flash_freq 40m .output/eagle/debug/image/eagle.app.v6.out -o ../bin/
esptool.py v1.2-dev
../tools/esptool.py:1139: DeprecationWarning: inspect.getargspec() is deprecated, use inspect.signature() or inspect.getfullargspec()
  operation_args,_,_,_ = inspect.getargspec(operation_func)
Traceback (most recent call last):
  File "../tools/esptool.py", line 1233, in <module>
    main()
  File "../tools/esptool.py", line 1146, in main
    operation_func(args)
  File "../tools/esptool.py", line 898, in elf2image
    image.add_segment(e.get_symbol_addr(start), data)
  File "../tools/esptool.py", line 522, in get_symbol_addr
    return self.symbols[sym]
KeyError: '_text_start'
make[1]: *** [../Makefile:204: .output/eagle/debug/bin/eagle.app.v6.bin] Error 1
make[1]: Leaving directory '/home/robby/builds/nodemcu-firmware/app'
make: *** [Makefile:292: .subdirs] Error 2

python --version outputs: Python 3.7.1

I tried to find similiar bug-reports, but could not find anythin regarding the python deprectiation message and nodemcu.

Am I the only one trying to build with python 3.7.1?

devsaurus commented 5 years ago

The local copy of esptool.py is quite old and not prepared for python3. E.g. upstream esptool.py calls different functions for python2 and 3.

Am I the only one trying to build with python 3.7.1?

At least this is the only report related to python 3.

There are some dedicated changes in our local copy, thus it's probably not safe to exchange tools/esptool.py with the latest version from upstream.

LongnoseRob commented 5 years ago

Am I the only one trying to build with python 3.7.1? At least this is the only report related to python 3.

Interesting, I thought python 3 would be default on any decent distro. Anyway had to fix several print commands in esptool before (missing ()).

Letme see if I can fix this with some tinkering and research how other projects fixed this issue..

LongnoseRob commented 5 years ago

As a temporary fix, I tried using esprool.py V.2.5.1 (from upstream), which seems to work at least for the moment. Bus as I have only esp8266 and no esp32 module this is just a dirty hack..

marcelstoer commented 5 years ago

The local copy of esptool.py is quite old and not prepared for python3.

When I noticed this issue I went "Oh no, there we go again. We really shouldn't be hosting our own copy of that thing.". Upstream has been so stable over the last two years we should really reconsider this IMHO.

devsaurus commented 5 years ago

We really shouldn't be hosting our own copy of that thing.

Sure.

The only reason that might block moving to upstream IMO is https://github.com/nodemcu/nodemcu-firmware/commit/b0f9788a6d02609dc31a1a3360ad79210e3443e2#diff-e6e8c9cf42985f99554a22a8a34b90e4 Is this still required?

marcelstoer commented 5 years ago

Dunno, tagging @jmattsson

jmattsson commented 5 years ago

Yes, that one is still needed, since otherwise the generated binary would not execute our trampoline code which installs the exception handler. Would someone be able to submit a patch for upstream for this? I don't have time just now, but could look at it next week(?) if no one beats me to it. It'd be safe to get it into mainline, since the behaviour I added is just removing the assumption about what the entry point is called, and reading the actual entry point from the ELF instead.

TerryE commented 5 years ago

I have taken a look at the I've been looking through this wider issue, because of the V3 SDK upgrade and the addition of partition table support. The latest Espressif esptool.py works fine for 0x00000.bin + 0x10000.bin loads (and which is a lot faster than our tools version since it downloads an inflate-enabled bootstrap which supports streaming of compressed images).

I've got rid of a family load of over-Xmas guests and life is getting back to normal, so I will look at the issue tomorrow.

TerryE commented 5 years ago

The only reason that might block moving to upstream IMO is this. Is this still required?

We've customised esptool.py so that it picks out the start address using a call to xtensa-lx106-elf-readelf -hon the out file in the Makefile command $(ESPTOOL) elf2image --flash_mode dio --flash_freq 40m $< -o $(FIRMWAREDIR). However, the latest version of esptool works for me from the commandline fine, so I checked and doing:

> ~/bin/esptool.py elf2image --flash_mode dio --flash_freq 40m \
   .output/eagle/debug/image/eagle.app.v6.out -e 1 -o ../bin/
esptool.py v2.6-beta1
Creating image for ESP8266...

> ~/nodemcu-firmware/app$ ~/bin/esptool.py image_info ../bin/0x00000.bin
esptool.py v2.6-beta1
Image version: 1
Entry point: 40106074
3 segments
Segment 1: len 0x07a74 load 0x40100000 file_offs 0x00000008
Segment 2: len 0x008c4 load 0x3ffe8000 file_offs 0x00007a84
Segment 3: len 0x00088 load 0x3ffe88c4 file_offs 0x00008350
Checksum: 39 (valid)
> ~/nodemcu-firmware/app$ grep 40106074 mapfile
                0x0000000040106074                user_start_trampoline

So the current version already picks up the ELF2 entry point fine. If this entry point issue is why we forked he esptool, then this a case of the bug having been swept up in subsequent version upgrade of the tool, IMO.

The latest esptool has all sorts of goodies including compression and it includes the same of logic as we use in user_start_trampoline to set the SPIFlashInfo size byte.

TerryE commented 5 years ago

I suggest that we close this and continue this debate in #2404