cpu/esp*: fix linker scripts #15186

leandrolanzieri · 2020-10-08T10:04:05Z

Contribution description

esp32 and esp8266 specify some modules' object files on their linker scripts. #14754 changed the compilation of RIOT modules, so archives are not generated anymore. This was causing the wildcards on the linker scripts to not match the object files. This PR fixes this issue by using the folder instead of the archive name.

With these changes esp8266 is working again, and for esp32 I ran the mtd test successfully (#15123).

Testing procedure

both platforms should be functional again, it would be good to run the tests on the CI.
check in the linker scripts that no more non-existent archives are being referenced.

Issues/PRs references

Fixes ESP8266 does not respond #15137
Fixes esp32: mtd tests failing on CI #15123
Issue introduced in build system: link object files #14754

benpicco · 2020-10-08T10:14:36Z

I think we can also revert d59fd84 now.

kaspar030 · 2020-10-08T10:16:29Z

good job @leandrolanzieri!

I think we can also revert d59fd84 now.

would you do that and then enable CI tests & build?

leandrolanzieri · 2020-10-08T10:21:04Z

I think we can also revert d59fd84 now.

would you do that and then enable CI tests & build?

Done! I reverted the blacklisting commit and triggered the CI.

leandrolanzieri · 2020-10-08T12:04:52Z

tests/lwip_sock_tcp seems to be failing because xtimer_init is called from the application while auto_init_xtimer module is used. That causes the second attempt of initialization to fail.

Should I disable auto_init_xtimer for that test?

leandrolanzieri · 2020-10-08T12:14:58Z

Should I disable auto_init_xtimer for that test?

The test application itself is calling xtimer_init twice as well. One of those should be removed.

I could instead remove both calls and leave auto_init_xtimer active.

fjmolinas · 2020-10-08T12:29:10Z

Should I disable auto_init_xtimer for that test?

The test application itself is calling xtimer_init twice as well. One of those should be removed.

I could instead remove both calls and leave auto_init_xtimer active.

I would remove the extra call, unless there is a reason for late initiation @miri64?

miri64 · 2020-10-08T13:35:15Z

I would remove the extra call, unless there is a reason for late initiation @miri64?

The reason for xtimer_init() is because it did not use to include auto_init. That changed with e0855de, which is by you @fjmolinas. So I guess I can play the hot potato back to you ;-).

fjmolinas · 2020-10-08T14:07:50Z

The reason for xtimer_init() is because it did not use to include auto_init. That changed with e0855de, which is by you @fjmolinas. So I guess I can play the hot potato back to you ;-).

Yes I know, I was not playing hot potato, just asking if it was safe to remove.

fjmolinas · 2020-10-08T14:13:18Z

Yes I know, I was not playing hot potato, just asking if it was safe to remove.

Opened.

This reverts commit d59fd84.

benpicco · 2020-10-09T13:40:04Z

Only failure due to #15066 it seems

benpicco

All tests succeed again now, failure on samr21 is unrelated.

leandrolanzieri · 2020-10-09T14:30:39Z

Backport provided in #15197

leandrolanzieri · 2020-10-09T14:31:18Z

Thanks for the review!

benpicco · 2020-10-09T14:38:10Z

An observation (not sure if related):

examples/gnrc_border_router crashes when enabling the gnrc_ipv6_nib_dns module on esp32 (Only adding sock_dns works, but then DNS information is not distributed in the network)

2020-10-09 16:33:45,020 # EXCEPTION!! exccause=0 (IllegalInstructionCause) @800d081b excvaddr=00000000
2020-10-09 16:33:45,021 # processes:
2020-10-09 16:33:45,030 # 	pid | name                 | state    Q | pri | stack  ( used) ( free) | base addr  | current     
2020-10-09 16:33:45,038 # 	  - | isr_stack            | -        - |   - |   2048 (    0) ( 2048) | 0x3ffb0000 | 0x3ffb0800
2020-10-09 16:33:45,047 # 	  1 | wifi-event-loop      | bl rx    _ |   4 |   2104 (  548) ( 1556) | 0x3ffaefcc | 0x3ffaf5e0 
2020-10-09 16:33:45,055 # 	  2 | idle                 | pending  Q |  31 |   2048 (  304) ( 1744) | 0x3ffb21a0 | 0x3ffb2870 
2020-10-09 16:33:45,064 # 	  3 | main                 | pending  Q |  15 |   3072 (  704) ( 2368) | 0x3ffb29a0 | 0x3ffb32e0 
2020-10-09 16:33:45,072 # 	  4 | 6lo                  | bl rx    _ |  11 |   2048 (  580) ( 1468) | 0x3ffb9ba4 | 0x3ffba160 
2020-10-09 16:33:45,081 # 	  5 | ipv6                 | bl rx    _ |  12 |   2048 (  600) ( 1448) | 0x3ffb68f8 | 0x3ffb6ea0 
2020-10-09 16:33:45,090 # 	  6 | udp                  | bl rx    _ |  13 |   2048 (  568) ( 1480) | 0x3ffba788 | 0x3ffbad50 
2020-10-09 16:33:45,098 # 	  7 | at86rf2xx            | running  Q |  10 |   2048 ( 1376) (  672) | 0x3ffb7a40 | 0x3ffb7f40 
2020-10-09 16:33:45,104 # 	    | SUM                  |            |     |  17464 ( 4680) (12784)
2020-10-09 16:33:45,105 # 
2020-10-09 16:33:45,109 # heap: 140524 (used 4452, free 136072) [bytes]
2020-10-09 16:33:45,109 # 
2020-10-09 16:33:45,110 # register set
2020-10-09 16:33:45,117 # pc      : 400e6898	ps      : 00060f30	exccause: 00000000	excvaddr: 00000000
2020-10-09 16:33:45,123 # epc1    : 400e6898	epc2    : 400edab8	epc3    : 00000000	epc4    : 00000000
2020-10-09 16:33:45,129 # epc5    : 00000000	epc6    : 00000000	epc7    : 00000000	
2020-10-09 16:33:45,135 # a0      : 800d081b	a1      : 3ffb8090	a2      : 3ffb8338	a3      : 00000001
2020-10-09 16:33:45,142 # a4      : 3ffb808c	a5      : 000a2224	a6      : ffffffff	a7      : 00000000
2020-10-09 16:33:45,149 # a8      : 800d071c	a9      : 3ffb8070	a10     : 00000000	a11     : 00000005
2020-10-09 16:33:45,155 # a12     : 00000081	a13     : 00000000	a14     : 00000000	a15     : 3ffb42f8
2020-10-09 16:33:45,160 # lbeg    : 00000000	lend    : 00000000	lcount  : 00000000
2020-10-09 16:33:51,014 # ets Jun  8 2016 00:22:57
2020-10-09 16:33:51,014 # 
2020-10-09 16:33:51,019 # rst:0x7 (TG0WDT_SYS_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)

edit only happens when I use at86rf233 instead of esp_now, addr2line points to spi_transfer_reg() oO

This is 'fixed' by doing

--- a/cpu/esp32/ld/esp32.common.ld
+++ b/cpu/esp32/ld/esp32.common.ld
@@ -129,6 +129,7 @@ SECTIONS
     *spiffs/*(.literal .text .literal.* .text.*)
     *syscalls.o(.literal .text .literal.* .text.*)
     *vfs/*(.literal .text .literal.* .text.*)
+    *at86rf2xx/*(.literal .text .literal.* .text.*)
 
     /* part of the RIOT port that should run in IRAM */
     *cpu/*(.literal .text .literal.* .text.*)

but that can't be the proper solution.

benpicco · 2020-10-09T14:59:16Z

cpu/esp8266/ld/esp8266.riot-os.ld

@@ -286,7 +286,7 @@ SECTIONS
    *libc.a:*fputwc.o(.literal .text .literal.* .text.*)
    */

-    enc28j60.a:*(.literal .text .literal.* .text.*)
+    *enc28j60/*(.literal .text .literal.* .text.*)


What's with this random driver getting special treatment 🤔

I'm not really sure, maybe @gschorcht can clarify?

Hm, yes I can clarify. In section Network Devices of the ESP8266 documentation it is mentioned that ESP8266 is working and has been tested with ENC28J60 and MRF24J40. However, the ENC28J60 works only if the driver code is placed in IRAM.

Since the IRAM of the ESP8266 is very limited and only has a size of 48 kByte, it is not possible to place code segments in the IRAM by default. The IROM of the ESP8266 on the other hand has 448 kByte. The IRAM is of course much faster, while the IROM is much slower and can only be accessed via a cache, which is also sometimes disabled, e.g. by the WiFi module or when writing to the flash.

Therefore, time-critical code as well as code that has to work even when the cache is disabled must be placed in the IRAM. Due to the limited size of the IRAM, fine-tuning is always required as to what must be placed in the IRAM and what can be placed in the IROM.

IROM is much slower and can only be accessed via a cache, which is also sometimes disabled, e.g. by the WiFi module

The WiFi module disabling the cache is surprising! Wouldn't that mean that any code can be hit by the problem if another task gets scheduled while the WiFi driver has the cache disabled? Or are interrupts disabled together with the cache?

@benpicco I'm not really sure (I just forgot too much in last 2 years doing other things 😟), but when I remember correctly, I had problems to access IROM when the WiFi module was active. So my guess at that time was (without knowing it definitely, there is no documentation) that it might be that the WiFi module is connected via SPI inside the SoC. That's why esp_wifi is already in IRAM. I could try it again.

leandrolanzieri added this to the Release 2020.10 milestone Oct 8, 2020

leandrolanzieri requested review from benpicco, bergzand, fjmolinas and gschorcht October 8, 2020 10:04

leandrolanzieri mentioned this pull request Oct 8, 2020

build system: link object files #14754

Merged

benpicco requested a review from kaspar030 October 8, 2020 10:14

fjmolinas requested a review from maribu October 8, 2020 10:16

leandrolanzieri requested review from aabadie, MichelRottleuthner and smlng as code owners October 8, 2020 10:19

leandrolanzieri added CI: run tests If set, CI server will run tests on hardware for the labeled PR CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Oct 8, 2020

fjmolinas mentioned this pull request Oct 8, 2020

tests/lwip_sock_tcp: remove duplicated xtimer_init #15189

Merged

fjmolinas mentioned this pull request Oct 9, 2020

tests/lwip_sock_tcp: remove duplicated xtimer_init [backport 2020.10] #15191

Merged

leandrolanzieri added 2 commits October 9, 2020 13:29

cpu/esp32/ld: use folder name instead of archive for module objects

837ddf6

cpu/esp8266/ld: use folder name instead of archive for module objects

eb2655b

tests: remove esp32-wroom-32 from blacklist of mtd using tests

b897637

This reverts commit d59fd84.

leandrolanzieri force-pushed the pr/esp/fix_linker_scripts branch from d59eaa3 to b897637 Compare October 9, 2020 11:30

benpicco approved these changes Oct 9, 2020

View reviewed changes

benpicco added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Oct 9, 2020

benpicco merged commit c21b72b into RIOT-OS:master Oct 9, 2020

leandrolanzieri deleted the pr/esp/fix_linker_scripts branch October 9, 2020 14:27

leandrolanzieri mentioned this pull request Oct 9, 2020

cpu/esp*: fix linker scripts [backport 2020.10] #15197

Merged

benpicco reviewed Oct 9, 2020

View reviewed changes

kaspar030 mentioned this pull request Mar 3, 2021

boards/esp32-wroom-32: tests/mtd_raw flakey #16130

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cpu/esp*: fix linker scripts #15186

cpu/esp*: fix linker scripts #15186

leandrolanzieri commented Oct 8, 2020

benpicco commented Oct 8, 2020

kaspar030 commented Oct 8, 2020

leandrolanzieri commented Oct 8, 2020

leandrolanzieri commented Oct 8, 2020

leandrolanzieri commented Oct 8, 2020

fjmolinas commented Oct 8, 2020

miri64 commented Oct 8, 2020

fjmolinas commented Oct 8, 2020

fjmolinas commented Oct 8, 2020

benpicco commented Oct 9, 2020

benpicco left a comment

leandrolanzieri commented Oct 9, 2020

leandrolanzieri commented Oct 9, 2020

benpicco commented Oct 9, 2020 •

edited

Loading

benpicco Oct 9, 2020

leandrolanzieri Oct 9, 2020

gschorcht Oct 30, 2021

benpicco Oct 30, 2021

gschorcht Oct 31, 2021

cpu/esp*: fix linker scripts #15186

cpu/esp*: fix linker scripts #15186

Conversation

leandrolanzieri commented Oct 8, 2020

Contribution description

Testing procedure

Issues/PRs references

benpicco commented Oct 8, 2020

kaspar030 commented Oct 8, 2020

leandrolanzieri commented Oct 8, 2020

leandrolanzieri commented Oct 8, 2020

leandrolanzieri commented Oct 8, 2020

fjmolinas commented Oct 8, 2020

miri64 commented Oct 8, 2020

fjmolinas commented Oct 8, 2020

fjmolinas commented Oct 8, 2020

benpicco commented Oct 9, 2020

benpicco left a comment

Choose a reason for hiding this comment

leandrolanzieri commented Oct 9, 2020

leandrolanzieri commented Oct 9, 2020

benpicco commented Oct 9, 2020 • edited Loading

benpicco Oct 9, 2020

Choose a reason for hiding this comment

leandrolanzieri Oct 9, 2020

Choose a reason for hiding this comment

gschorcht Oct 30, 2021

Choose a reason for hiding this comment

benpicco Oct 30, 2021

Choose a reason for hiding this comment

gschorcht Oct 31, 2021

Choose a reason for hiding this comment

benpicco commented Oct 9, 2020 •

edited

Loading