nodemcu-firmware
nodemcu-firmware copied to clipboard
nodemcu
ESP32: Trying to build with the current IDF
I just received one of the ESP32-C3 demo boards and so I thought that I'd get my feet wet with the nodemcu/esp32 code. However, it looks as though the version of the IDF that we are using is quite old, and when I upgrade to the current master branch, nothing really works.
The base makefile in nodemcu-firmware doesn't actually build anything (once you have the idf installed and configured). Worse, I don't seem able to get the nodemcu components included. If I do make menuconfig then nodemcu shows up, but it doesn't appear to put anything useful into sdkconfig. If I do idf.py menuconfig then the nodemcu config doesn't even show up.
Is there anybody who understands the nodemcu/idf build system? Can it be made to work with the current idf master branch (or even the release/v4.3 branch)?
As we're on 3.x LTS (see #3196) I expect upgrading to 4.x will be quite a bit of work. In theory it should "just" be the list of breaking changes that came with https://github.com/espressif/esp-idf/releases/tag/v4.0 but surprises wouldn't surprise me.
Is there anybody who understands the nodemcu/idf build system?
At least @jmattsson should be familiar with it.
I recall Angus saying something about them switching from GNU make to cmake with the 4.0 release, so probably no compatibility whatsoever between those two releases. I'm woefully out of date on my knowledge and experience here though :/
I'm making progress by making random changes to things and have been having some success. I'm able to get some of nodemcu to build and it is mostly around weird include path problems that is hampering me at the moment.
On Thu, Feb 11, 2021 at 9:02 PM Johny Mattsson [email protected] wrote:
I recall Angus saying something about them switching from GNU make to cmake with the 4.0 release, so probably no compatibility whatsoever between those two releases. I'm woefully out of date on my knowledge and experience here though :/
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-777919371, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTIGNLU3VENTHQIYJRLS6SD4VANCNFSM4XOAOVRQ .
I have a branch pjsg:idf4 that is my work in progress if anyone is
interested....
On Thu, Feb 11, 2021 at 9:56 PM Philip Gladstone [email protected] wrote:
I'm making progress by making random changes to things and have been having some success. I'm able to get some of nodemcu to build and it is mostly around weird include path problems that is hampering me at the moment.
On Thu, Feb 11, 2021 at 9:02 PM Johny Mattsson [email protected] wrote:
I recall Angus saying something about them switching from GNU make to cmake with the 4.0 release, so probably no compatibility whatsoever between those two releases. I'm woefully out of date on my knowledge and experience here though :/
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-777919371, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTIGNLU3VENTHQIYJRLS6SD4VANCNFSM4XOAOVRQ .
I can get an image to build and I can flash it, but it doesn't work. Any ideas on how to debug this?
load:0x40078000,len:0 ho 12 tail 0 room 4 load:0x40078000,len:15000 entry 0x40078630 [0;32mI (30) boot: ESP-IDF v3.1-dev-1381-g9a55b42f 2nd stage bootloader [0m [0;32mI (30) boot: compile time 18:01:16 [0m [0;32mI (30) boot: Enabling RNG early entropy source... [0m [0;32mI (36) boot: SPI Speed : 40MHz [0m [0;32mI (40) boot: SPI Mode : DIO [0m [0;32mI (44) boot: SPI Flash Size : 4MB [0m [0;32mI (48) boot: Partition Table: [0m [0;32mI (52) boot: ## Label Usage Type ST Offset Length [0m [0;32mI (59) boot: 0 nvs WiFi data 01 02 00009000 00006000 [0m [0;32mI (66) boot: 1 phy_init RF data 01 01 0000f000 00001000 [0m [0;32mI (74) boot: 2 factory factory app 00 00 00010000 00100000 [0m [0;32mI (81) boot: End of partition table [0m [0;32mI (86) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x109c8 ( 68040) map [0m [0;32mI (118) esp_image: segment 1: paddr=0x000209f0 vaddr=0x3ffb0000 size=0x02d34 ( 11572) load [0m [0;32mI (123) esp_image: segment 2: paddr=0x0002372c vaddr=0x40080000 size=0x0c8ec ( 51436) load [0m [0;32mI (146) esp_image: segment 3: paddr=0x00030020 vaddr=0x400d0020 size=0x41760 (268128) map [0m [0;32mI (241) esp_image: segment 4: paddr=0x00071788 vaddr=0x4008c8ec size=0x01040 ( 4160) load [0m [0;32mI (251) boot: Loaded app from partition at offset 0x10000 [0m [0;32mI (251) boot: Disabling RNG early entropy source... [0m
then nothing..... The link map shows that the app_main is being included....
Philip
On Thu, Feb 11, 2021 at 9:58 PM Philip Gladstone [email protected] wrote:
I have a branch
pjsg:idf4that is my work in progress if anyone is interested....On Thu, Feb 11, 2021 at 9:56 PM Philip Gladstone < [email protected]> wrote:
I'm making progress by making random changes to things and have been having some success. I'm able to get some of nodemcu to build and it is mostly around weird include path problems that is hampering me at the moment.
On Thu, Feb 11, 2021 at 9:02 PM Johny Mattsson [email protected] wrote:
I recall Angus saying something about them switching from GNU make to cmake with the 4.0 release, so probably no compatibility whatsoever between those two releases. I'm woefully out of date on my knowledge and experience here though :/
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-777919371, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTIGNLU3VENTHQIYJRLS6SD4VANCNFSM4XOAOVRQ .
See if the gdbstub is alive. If you can hook in with gdb you should be able to make short work of the debugging. Docs e.g. https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools/idf-monitor.html
Failing that, try printf'ing your way through the start-up (that's what I normally end up doing).
If you're still not getting somewhere, modifying the bootloader to actually show the address it's jumping to when it thinks it's starting the app might be useful / give you a clue.
On Sun, 14 Feb 2021 at 11:24, Philip Gladstone [email protected] wrote:
I can get an image to build and I can flash it, but it doesn't work. Any ideas on how to debug this?
load:0x40078000,len:0 ho 12 tail 0 room 4 load:0x40078000,len:15000 entry 0x40078630 [0;32mI (30) boot: ESP-IDF v3.1-dev-1381-g9a55b42f 2nd stage bootloader [0m [0;32mI (30) boot: compile time 18:01:16 [0m [0;32mI (30) boot: Enabling RNG early entropy source... [0m [0;32mI (36) boot: SPI Speed : 40MHz [0m [0;32mI (40) boot: SPI Mode : DIO [0m [0;32mI (44) boot: SPI Flash Size : 4MB [0m [0;32mI (48) boot: Partition Table: [0m [0;32mI (52) boot: ## Label Usage Type ST Offset Length [0m [0;32mI (59) boot: 0 nvs WiFi data 01 02 00009000 00006000 [0m [0;32mI (66) boot: 1 phy_init RF data 01 01 0000f000 00001000 [0m [0;32mI (74) boot: 2 factory factory app 00 00 00010000 00100000 [0m [0;32mI (81) boot: End of partition table [0m [0;32mI (86) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x109c8 ( 68040) map [0m [0;32mI (118) esp_image: segment 1: paddr=0x000209f0 vaddr=0x3ffb0000 size=0x02d34 ( 11572) load [0m [0;32mI (123) esp_image: segment 2: paddr=0x0002372c vaddr=0x40080000 size=0x0c8ec ( 51436) load [0m [0;32mI (146) esp_image: segment 3: paddr=0x00030020 vaddr=0x400d0020 size=0x41760 (268128) map [0m [0;32mI (241) esp_image: segment 4: paddr=0x00071788 vaddr=0x4008c8ec size=0x01040 ( 4160) load [0m [0;32mI (251) boot: Loaded app from partition at offset 0x10000 [0m [0;32mI (251) boot: Disabling RNG early entropy source... [0m
then nothing..... The link map shows that the app_main is being included....
Philip
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-778698535, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGUJZZYMF74QBBYFS2MV4DS64J2TANCNFSM4XOAOVRQ .
I now have a version that boots on the esp32 with v4 of the IDF. I have a file system, and I have wifi (though not the net module).
W (144629) phy_init: failed to load RF calibration data (0x1102), falling
back to full calibration
I (144789) wifi:mode : sta (24:0a:c4:06:f4:f4)
I (144789) wifi:enable tsf
> I (144799) wifi:new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1
I (145469) wifi:state: init -> auth (b0)
I (145479) wifi:state: auth -> assoc (0)
I (145479) wifi:state: assoc -> run (10)
I (145509) wifi:connected with Chateau Gladstone Guest, aid = 4, channel 1,
BW20, bssid = e2:63:da:7d:38:79
I (145509) wifi:security: WPA2-PSK, phy: bgn, rssi: -77
I (145509) wifi:pm start, type: 1
I (145589) wifi:AP's beacon interval = 102400 us, DTIM period = 3
W (145779) wifi:<ba-add>idx:0 (ifx:0, e2:63:da:7d:38:79), tid:0, ssn:1,
winSize:64
I (146779) esp_netif_handlers: sta ip: 192.168.103.140, mask:
255.255.255.0, gw: 192.168.103.1
However, the dev-esp32 branch is really old and I suspect that we really need to move to a much more common codebase.
Another issue is that the code size seems huge -- the nodemcu wifi module brings in maybe 400kb of code space and blew the 1MB code segment size. I actually switched to using -O2 and that brought it down somewhat. I can increase the partition size, but that seems wrong as well.
Anyway, my goal in all of this was to try and do the port to the esp32c3 which is (apparently) intended to be the new ESP8266 and come out at a similar price point. That task is up next, but at least I know that I have a roughly working codebase!
For those of you that haven't seen the new part, this is a side-by-side photo with a standard ESP32 dev board. It certainly could fit into a D1 Mini sized PCB. There is nothing on the underside of the new board and only silicon (as far as I can see) is the CP2104 USB/Serial interface, and some voltage regulators and what looks like a very small WS2812 -- but I have no idea what that part is.
[image: PXL_20210218_005422607.jpg] Philip
On Sat, Feb 13, 2021 at 10:22 PM Johny Mattsson [email protected] wrote:
See if the gdbstub is alive. If you can hook in with gdb you should be able to make short work of the debugging. Docs e.g.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools/idf-monitor.html
Failing that, try printf'ing your way through the start-up (that's what I normally end up doing).
If you're still not getting somewhere, modifying the bootloader to actually show the address it's jumping to when it thinks it's starting the app might be useful / give you a clue.
On Sun, 14 Feb 2021 at 11:24, Philip Gladstone [email protected] wrote:
I can get an image to build and I can flash it, but it doesn't work. Any ideas on how to debug this?
load:0x40078000,len:0 ho 12 tail 0 room 4 load:0x40078000,len:15000 entry 0x40078630 [0;32mI (30) boot: ESP-IDF v3.1-dev-1381-g9a55b42f 2nd stage bootloader [0m [0;32mI (30) boot: compile time 18:01:16 [0m [0;32mI (30) boot: Enabling RNG early entropy source... [0m [0;32mI (36) boot: SPI Speed : 40MHz [0m [0;32mI (40) boot: SPI Mode : DIO [0m [0;32mI (44) boot: SPI Flash Size : 4MB [0m [0;32mI (48) boot: Partition Table: [0m [0;32mI (52) boot: ## Label Usage Type ST Offset Length [0m [0;32mI (59) boot: 0 nvs WiFi data 01 02 00009000 00006000 [0m [0;32mI (66) boot: 1 phy_init RF data 01 01 0000f000 00001000 [0m [0;32mI (74) boot: 2 factory factory app 00 00 00010000 00100000 [0m [0;32mI (81) boot: End of partition table [0m [0;32mI (86) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x109c8 ( 68040) map [0m [0;32mI (118) esp_image: segment 1: paddr=0x000209f0 vaddr=0x3ffb0000 size=0x02d34 ( 11572) load [0m [0;32mI (123) esp_image: segment 2: paddr=0x0002372c vaddr=0x40080000 size=0x0c8ec ( 51436) load [0m [0;32mI (146) esp_image: segment 3: paddr=0x00030020 vaddr=0x400d0020 size=0x41760 (268128) map [0m [0;32mI (241) esp_image: segment 4: paddr=0x00071788 vaddr=0x4008c8ec size=0x01040 ( 4160) load [0m [0;32mI (251) boot: Loaded app from partition at offset 0x10000 [0m [0;32mI (251) boot: Disabling RNG early entropy source... [0m
then nothing..... The link map shows that the app_main is being included....
Philip
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-778698535 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAGUJZZYMF74QBBYFS2MV4DS64J2TANCNFSM4XOAOVRQ
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-778716439, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTKANOTITVMODCXFGGDS646XLANCNFSM4XOAOVRQ .
After ignoring all the warnings in the esp32-c3 build and disabling a bunch more modules, it boots:
(60) boot_comm: chip revision: 2, min. bootloader chip revision: 0
I (67) boot.esp32c3: SPI Speed : 80MHz
I (72) boot.esp32c3: SPI Mode : DIO
I (77) boot.esp32c3: SPI Flash Size : 4MB
I (82) boot: Enabling RNG early entropy source...
I (87) boot: Partition Table:
I (91) boot: ## Label Usage Type ST Offset Length
I (98) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (105) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (113) boot: 2 factory factory app 00 00 00010000 00177000
I (120) boot: 3 node_spiffs unknown c2 00 00187000 00100000
I (128) boot: End of partition table
I (132) boot_comm: chip revision: 2, min. application chip revision: 0
I (139) esp_image: segment 0: paddr=00010020 vaddr=3c0e0020 size=252bch
(152252) map
I (172) esp_image: segment 1: paddr=000352e4 vaddr=3fc8f400 size=033c8h (
13256) load
I (175) esp_image: segment 2: paddr=000386b4 vaddr=40380000 size=07964h (
31076) load
I (183) esp_image: segment 3: paddr=00040020 vaddr=42000020 size=d1fe4h
(860132) map
I (320) esp_image: segment 4: paddr=0011200c vaddr=40387964 size=07994h (
31124) load
I (326) esp_image: segment 5: paddr=001199a8 vaddr=50000000 size=00004h (
4) load
I (332) boot: Loaded app from partition at offset 0x10000
I (332) boot: Disabling RNG early entropy source...
I (349) cpu_start: Pro cpu up.
I (406) cpu_start: Pro cpu start user code
I (406) cpu_start: cpu freq: 160000000
I (406) cpu_start: Application information:
I (409) cpu_start: Project name: nodemcu
I (414) cpu_start: App version: 1.4.0-master_20151229-779-g1459
I (421) cpu_start: Compile time: Feb 17 2021 21:17:50
I (427) cpu_start: ELF file SHA256: 6450465877ed63d3...
I (433) cpu_start: ESP-IDF: v4.4-dev-4-g73db14240-dirty
I (439) heap_init: Initializing. RAM available for dynamic allocation:
I (447) heap_init: At 3FC981E0 len 00027E20 (159 KiB): DRAM
I (453) heap_init: At 3FCC0000 len 0001F260 (124 KiB): STACK/DRAM
I (460) heap_init: At 50000004 len 00001FFC (7 KiB): FAKEDRAM
I (466) spi_flash: detected chip: generic
I (471) spi_flash: flash io: dio
I (475) cpu_start: Starting scheduler.
怘��������fx~x�������f��fx�fx�~fx����x��f��~����~������怘�怘����~�����~����f���fx��~f�xxff�������fx����fx�fx~f�~f��xff��~怘��ff�~�x��f�����f~�x��f�xf��f~�xx��f��fx�`f~�xx��x���`ff~�xx���f��ff~�x~�xx�xf�x`f~���xf~�x�x�x�x���f��xf~�xx��f��fxx����f~�xx��f��fxx���~�xx��f��fxx���f~�xx��f��fx`������x~��x~�xx��f��fx����~���f~�xx��f����~������~��~�x�f�`����x~�xx��f��fxf���x~���f~��f~���~���~���f~��f~��f~��f��~���`fx~�f�`��f`~����~ff~�xf`fx~��x��x�����fffff�~�����fxf�~�x�����ffff~��fxf�~���昀���f��`~���怘�f~������fx���f�~怘�xf��fx~`�x�x~�����xx���xx��f��fxx���x�x`f���xx��f�f�������x��x���xf��fxf~�x�x�x�x`�x�f`�xx��f�����x��xx��f��fxf�xx��f����`�xx��f��fx`���x����xf��fx~~�xx�x��`�x��~����x`f��x�`�x`���xx��x�x�x�x�x�f`���xf��fx�~�xf�x�xf�x�xx���xxf��f���xf��fx~x�xx��f��x�x���xx�xx��f��x����xff���xf��fx`~x`��xx��f�f�x��x~���xf��fxx~���xx��f������xx��f���������x�xx�����xf���x~x��fx�x�����xf���x~fffffffffffffff怘�xf���xf~�x~��x��xx���������xx���xf���x~~�f�����f�x~�����xx�x�x�x���xx���xf���x�~��xx�x~����~�x���x`�x`�xff`��fx��xxxff��������xxxf�������xf���x~�xxfx�fxxxfx�xx�x~����~fffxx�xx��f�f�x����xf���x`~f�xfx�f�xx��x�`��ff��x`�����xxx�`fx`x�xxxf�����x�xf���xx�xxx�`���怘�xf���xx~�x�x�x�x�xxfx�x�xfx�xxfxf�����x�x�xxx�xxfxf��������xf���~ff���xf��fx���xxfx�fxxxfx�xf���~���xxx�������fx��fx�xxfxxxf���xf��x~�xf�x�x����x�xxfxxxf��f�x���fx������fx`�xf�x�x~���f`�xx��x�xf������x`�����xf���~f�x��xf�x�xxf����x��ffxx��x�xx�x��fff�����xf�xx��ff�������xf��~�x�x����f�����xf�x~�������xxx�������fx��fx怘�xf���~�xf�x�x�xx�xxf�xf�����xxxx�xx�xx�xf���xff���xxfx���xf��~f�xf�����xx���xx�xx�x�xx�xx�xx�xx�xfxx�xx�xx�xx���x���xf�x~�xx�x��x�xxx��������x�xx�������x�f��x~��x�xxx`���x怘�xf�x~x`�������x���
But doesn't work.....😣
On Wed, Feb 17, 2021 at 8:03 PM Philip Gladstone [email protected] wrote:
I now have a version that boots on the esp32 with v4 of the IDF. I have a file system, and I have wifi (though not the net module).
W (144629) phy_init: failed to load RF calibration data (0x1102), falling back to full calibration I (144789) wifi:mode : sta (24:0a:c4:06:f4:f4) I (144789) wifi:enable tsf > I (144799) wifi:new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1 I (145469) wifi:state: init -> auth (b0) I (145479) wifi:state: auth -> assoc (0) I (145479) wifi:state: assoc -> run (10) I (145509) wifi:connected with Chateau Gladstone Guest, aid = 4, channel 1, BW20, bssid = e2:63:da:7d:38:79 I (145509) wifi:security: WPA2-PSK, phy: bgn, rssi: -77 I (145509) wifi:pm start, type: 1 I (145589) wifi:AP's beacon interval = 102400 us, DTIM period = 3 W (145779) wifi:<ba-add>idx:0 (ifx:0, e2:63:da:7d:38:79), tid:0, ssn:1, winSize:64 I (146779) esp_netif_handlers: sta ip: 192.168.103.140, mask: 255.255.255.0, gw: 192.168.103.1However, the dev-esp32 branch is really old and I suspect that we really need to move to a much more common codebase.
Another issue is that the code size seems huge -- the nodemcu wifi module brings in maybe 400kb of code space and blew the 1MB code segment size. I actually switched to using -O2 and that brought it down somewhat. I can increase the partition size, but that seems wrong as well.
Anyway, my goal in all of this was to try and do the port to the esp32c3 which is (apparently) intended to be the new ESP8266 and come out at a similar price point. That task is up next, but at least I know that I have a roughly working codebase!
For those of you that haven't seen the new part, this is a side-by-side photo with a standard ESP32 dev board. It certainly could fit into a D1 Mini sized PCB. There is nothing on the underside of the new board and only silicon (as far as I can see) is the CP2104 USB/Serial interface, and some voltage regulators and what looks like a very small WS2812 -- but I have no idea what that part is.
[image: PXL_20210218_005422607.jpg] Philip
On Sat, Feb 13, 2021 at 10:22 PM Johny Mattsson [email protected] wrote:
See if the gdbstub is alive. If you can hook in with gdb you should be able to make short work of the debugging. Docs e.g.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools/idf-monitor.html
Failing that, try printf'ing your way through the start-up (that's what I normally end up doing).
If you're still not getting somewhere, modifying the bootloader to actually show the address it's jumping to when it thinks it's starting the app might be useful / give you a clue.
On Sun, 14 Feb 2021 at 11:24, Philip Gladstone [email protected] wrote:
I can get an image to build and I can flash it, but it doesn't work. Any ideas on how to debug this?
load:0x40078000,len:0 ho 12 tail 0 room 4 load:0x40078000,len:15000 entry 0x40078630 [0;32mI (30) boot: ESP-IDF v3.1-dev-1381-g9a55b42f 2nd stage bootloader [0m [0;32mI (30) boot: compile time 18:01:16 [0m [0;32mI (30) boot: Enabling RNG early entropy source... [0m [0;32mI (36) boot: SPI Speed : 40MHz [0m [0;32mI (40) boot: SPI Mode : DIO [0m [0;32mI (44) boot: SPI Flash Size : 4MB [0m [0;32mI (48) boot: Partition Table: [0m [0;32mI (52) boot: ## Label Usage Type ST Offset Length [0m [0;32mI (59) boot: 0 nvs WiFi data 01 02 00009000 00006000 [0m [0;32mI (66) boot: 1 phy_init RF data 01 01 0000f000 00001000 [0m [0;32mI (74) boot: 2 factory factory app 00 00 00010000 00100000 [0m [0;32mI (81) boot: End of partition table [0m [0;32mI (86) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x109c8 ( 68040) map [0m [0;32mI (118) esp_image: segment 1: paddr=0x000209f0 vaddr=0x3ffb0000 size=0x02d34 ( 11572) load [0m [0;32mI (123) esp_image: segment 2: paddr=0x0002372c vaddr=0x40080000 size=0x0c8ec ( 51436) load [0m [0;32mI (146) esp_image: segment 3: paddr=0x00030020 vaddr=0x400d0020 size=0x41760 (268128) map [0m [0;32mI (241) esp_image: segment 4: paddr=0x00071788 vaddr=0x4008c8ec size=0x01040 ( 4160) load [0m [0;32mI (251) boot: Loaded app from partition at offset 0x10000 [0m [0;32mI (251) boot: Disabling RNG early entropy source... [0m
then nothing..... The link map shows that the app_main is being included....
Philip
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-778698535 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAGUJZZYMF74QBBYFS2MV4DS64J2TANCNFSM4XOAOVRQ
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-778716439, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTKANOTITVMODCXFGGDS646XLANCNFSM4XOAOVRQ .
Any success on this? or you have dropped this idea? Mainly thinking about ESP32-S2 but have no idea how and if at all ...
I stopped at this stage. I need to see if Espressif added the support into the IDF that we needed to get the linking to work. If so, then it ought to be possible to build a very limited subset of modules with the current IDF. I never tried building for the 8266, so I don't know if that would be viable.
On Tue, May 25, 2021 at 1:37 PM Modestas Bunokas @.***> wrote:
Any success on this? or you have dropped this idea? Mainly thinking about ESP32-S2 but have no idea how and if at all ...
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-848077193, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTLUN32N6HR6YUX7HC3TPPN5RANCNFSM4XOAOVRQ .
I'm hoping I'll be able to spend some time bringing the ESP32 branch up to the latest IDF in the near future. I'm guessing the smartest thing would be to start from your idf4 branch, @pjsg?
I would certainly take a look there. It is fairly hacked up and doesn't build most of nodemcu, but it built enough to get to a prompt. I don't know whether espressif ever fixed the linker issue...
On Thu, Jul 8, 2021, 03:36 Johny Mattsson @.***> wrote:
I'm hoping I'll be able to spend some time bringing the ESP32 branch up to the latest IDF in the near future. I'm guessing the smartest thing would be to start from your idf4 branch, @pjsg https://github.com/pjsg?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-876067464, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTOCZV6VCRJJCHKQPVTTWUDJPANCNFSM4XOAOVRQ .
I've just been going through the latest IDF documentation, and it looks like there's enough stuff in the linker fragment support to make things work now. I'll have to switch from our current null-terminated lists over to known-size arrays, but that should be easy enough.
I've also had a look through your branch, and if you're okay with it I think it'll be easier for me to start clean off dev-esp32 and then borrow heavily on a file-by-file or snippet-by-snippet basis so I can dodge the C3 stuff for now. I just don't want you to think I'd be doing it to steal your thunder - it certainly looks like you've done a great chunk of the heavy lifting already! :)
As long as $work doesn't give me new priorities I'm hoping to get onto this next week.
I'm fine with you starting again. I didn't really know what I was doing when I started. It didn't take me long to get to the stage that I got to. I'd start again as well!
Okay, so I've started this, but have now hit a bit of a snag. The new linker fragments support appears to only be available on the master branch and not v4.4-dev or earlier, and said master branch is not currently in a buildable state it seems (issue in newlib/locks.c). I'll see if I can find a workaround and/or work my way backwards to hopefully find a sweet spot where both things work.
Say @igrr, I don't suppose you have an estimate on when the nice KEEP()/ALIGN()/SURROUND() support is going to arrive on a named branch?
@jmattsson for the master branch you probably need to run install.sh, . ./export.sh and then idf.py fullclean — this is because the toolchain has recently been updated from esp-2020r3 to esp-2021r1. The build errors in locks.c you observe will disappear then.
We will create release/v4.4 around the end of August, and aim to release v4.4 around November.
@igrr Ah, thank you for those pointers, that saved me some hours of troubleshooting! I'm now back to dealing with my own issues instead 🤣 And much obliged with the release estimates! The new ld fragments support should make my life considerably easier going forward, once I've tamed the transition.
Okay, I believe I have this almost fully in the bag now over on this branch. What do people think of me pushing this to a (temporary) dev-esp32-idf4 branch under the nodemcu org for better exposure/testing? I'd be reluctant to PR this right away, since it's a significant change and there are a few changes which break backwards compatibility. Do we have any highly visible release notes somewhere that should also be updated? (Sorry, I've been out of the loop for too long)
@jpeletier I haven't touched the "extmod" stuff yet, since I've never used it and am thus not quite sure of usage / best way forward to migrate from the 3.x IDF build structure to the 4.x IDF for those. I'd welcome your (and others') input here.
@igrr In the end it wasn't possible to move everything over to _seg_start/_seg_end symbol usage, so I've done "something clever" to get the zero-termination happening, which I'm hoping won't turn out to be fragile, but if you'd consider a feature request to add a linker fragment option of e.g. APPEND_LONGS(n, val) to facilitate easier placement of zeroes after a SURROUND() block that would be welcome :)
What do people think of me pushing this to a (temporary) dev-esp32-idf4 branch under the nodemcu org for better exposure/testing?
By all means, go ahead!
Do we have any highly visible release notes somewhere
We only write release notes for master (erg.. release) drops. Hence, we've never had ESP32 releases. However, I'm sure people would appreciate up-to-date docs (what works, what doesn't) in the IDF 4 branch. If it won't mean too much work for me I could even make that branch available in the cloud builder. Maybe my existing scripts work out of the box?
Thanks @marcelstoer.
Okay, there's now a dev-esp32-idf4 branch here too :) The docs in this branch have been updated, so where there was once a function there is now a note saying it has been removed due to underlying functionality disappearing upstream. It could be nice to those items listed somewhere explicitly so people can come forewarned rather than find out once their code throws an error. I don't know where might be a good place for that. Suggestions welcome.
Your cloud builder scripts would need some tweaking to cope with the new things. make defconfig was removed, but you can probably replace it with cp sdkconfig.defaults sdkconfig. There's a new ./install.sh script which has to be run first, which chains through to the IDF's install.sh script automatically. Oh, and cmake needs to be available on the build host. If you're building in a directory where you previously had IDF 3.x, you'll also need to find . -name *.pyc | xargs rm to clean up interfering precompiled python things. And MORE_CFLAGS is no longer a thing. The integer-only build is an option in the sdkconfig now instead.
Oh, and I'd carefully updated the travis build script, only to discover that TravisCI.org is now fully gone. Do we have plans to migrate to something else, and if so what? (Somewhat tangential to the rest of the discussion, but...)
extmod
@jmattsson, drop this for now, I need to see the community demand to port this forward before dedicating effort, if it is only me I see no point yet. Thank you for your work on this, looks great btw
@pjsg I've also ordered myself a couple of C3 dev boards so I can start looking at that in a few weeks hopefully. We have some Xtensa-only assembler over in the lua component that we'll need to #ifdef properly now that we get RISC-V in the mix.
It could be nice to those items listed somewhere explicitly so people can come forewarned rather than find out once their code throws an error.
Absolutely. Add a chapter/paragraph to docs entry page?
Your cloud builder scripts would need some tweaking to cope with the new things.
Thanks for the analysis. I don't see me having the capacity to look after that for the moment. However, by the time we want to merge your work back to the dev-esp32 branch I would have to have it ready.
Btw, the cloud builder runs in a GitHub CI pipeline.
TravisCI.org is now fully gone. Do we have plans to migrate to something else
@HHHartmann migrated the non-ESP32 braches from Travis to GitHub CI half a year ago: https://github.com/nodemcu/nodemcu-firmware/commits/release/.github/workflows. However, at the time he left the .travis.yml untouched as the service was still available.
Thanks, I'll have a look at the github workflows then! I'm also thinking that it might be nice to branch off dev-esp32 to a dev-esp32-idf3-legacy branch to give people a better chance to migrate as we hop onto idf4 for main dev. Thoughts?
Any chance of using LUA 5.3 or later like https://github.com/UncleRus/esp-idf-lua? Just a stupid question, have no idea how complicated it could be. For me ESP32-S2 with SPIRAM looks ideal for LUA, but after getting hands dirty with ESP8266 and LUA 5.3 I would like to go with ESP32-S2 and LUA 5.3 or 5.4.x
Thank you
@KT819GM That is definitely on the cards. We're wanting to get to the point where we have a shared branch for both the ESP8226 and ESP32 so we can have as many features shared across both platforms as possible, including the new Lua version.
The path to get there is a bit challenging, seeing as we're still using the "non-OS" SDK on the ESP8266 which is very different from the RTOS & IDF on the ESP32 side. I'm hoping that now that $work has a desire for some of the features only available on the RTOS version in the 8266 SDK that I'll get some time to dedicate to this again. I had hoped to have had the branches merged well over a year ago, but then life & work & world circumstances changed 😩
I'm also thinking that it might be nice to branch off dev-esp32 to a dev-esp32-idf3-legacy
That might make sense once your IDF 4 branch is sufficiently stable. Just let me know when you're ready so I can adjust the cloud builder such that at least that legacy branch is still supported.
Any chance of using LUA 5.3 or later like https://github.com/UncleRus/esp-idf-lua
OT: Lua is not an acronym 😉 I can't assess the quality of that project but if someone is familiar with IDF and Lua then maybe she/he could be convinced to join forces with us?
Okay I've switched this branch over to github actions. The workflow is not as full-featured as on the esp8266 branch, but it's matching what the old travis build was doing at least. I've also fixed a couple of issues I found, and done a code-cleanup to sort out most of the warnings (the luac.cross build is still giving off a bunch, I may or may not investigate those).
We're slowly starting to test the idf4 stuff at $work, but that will only cover the parts we actually use, so everyone, please do dig in and tell me where I b0rked the upgrade :)