soc: esp32c3: fix TLS flash addressing

[sylvioalves]

When TLS is used, __tdata_start is PROVIDED by
"thread-local-storage.ld" using absolute address, which makes it land in wrong flash address. This causes risc-v startup code to fail during memcpy/memset.

This PR overrides __tdata_start to use ADDR, which will make sure it is placed in DROM region due to AT keyword.

Fixes #69708

[keith-packard]

This looks wrong to me -- LOADADDR(__tdata_start) is where the values for the initialized thread local data can be found in ROM while ADDR(__tdata_start) is a fake address used as a part of the thread local storage offset computations; it should match the reported base of the tdata section. TLS offsets are computed during linking by subtracting the fake address of the symbol from the base of the tdata section; those offsets are what are used to fetch values relative to the thread local storage base address (stored in the tp register on risc-v).

When initializing a newly allocated TLS block for a new thread, Zephyr copies bits from ROM into the parts of the new block corresponding to the initialized portion and then clears the portion corresponding to the zero-initialized portion.

Your patch seems like it will pull random data from RAM starting at the fake __tdata_start address instead of the correct values from ROM starting at LOADADDR(__tdata_start).

I'm betting we can't simply use memcpy from ROM on this chip and that we need to do something else to get the initialized values out of ROM and into each TLS block.

To check and make sure your fix works, you can try this version of samples/hello_world/src/main.c:

/*
 * Copyright (c) 2012-2014 Wind River Systems, Inc.
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include <stdio.h>

#define TLS_DATA_VALUE 42

__thread int tls_data_variable = TLS_DATA_VALUE;

int main(void)
{
	if (tls_data_variable == TLS_DATA_VALUE) {
		printf("SUCCESS\n");
	} else {
		printf("FAILURE: tls_data_variable is %d instead of %d\n", tls_data_variable, TLS_DATA_VALUE);
	}
	return 0;
}

[lgl88911]

This looks wrong to me -- LOADADDR(__tdata_start) is where the values for the initialized thread local data can be found in ROM while ADDR(__tdata_start) is a fake address used as a part of the thread local storage offset computations; it should match the reported base of the tdata section. TLS offsets are computed during linking by subtracting the fake address of the symbol from the base of the tdata section; those offsets are what are used to fetch values relative to the thread local storage base address (stored in the tp register on risc-v).这在我看来是错误的 - LOADADDR(__tdata_start) 是可以在 ROM 中找到初始化线程本地数据的值的位置，而 ADDR(__tdata_start) 是用作线程本地存储的一部分的假地址偏移计算；它应该与 tdata 部分报告的基数匹配。 TLS 偏移量是在链接期间通过从 tdata 部分的基数中减去符号的假地址来计算的；这些偏移量用于获取相对于线程本地存储基地址（存储在 risc-v 上的 tp 寄存器中）的值。

When initializing a newly allocated TLS block for a new thread, Zephyr copies bits from ROM into the parts of the new block corresponding to the initialized portion and then clears the portion corresponding to the zero-initialized portion.当为新线程初始化新分配的 TLS 块时，Zephyr 将位从 ROM 复制到新块中与初始化部分相对应的部分，然后清除与零初始化部分相对应的部分。

Your patch seems like it will pull random data from RAM starting at the fake __tdata_start address instead of the correct values from ROM starting at LOADADDR(__tdata_start).您的补丁似乎会从假 __tdata_start 地址开始从 RAM 中提取随机数据，而不是从 LOADADDR(__tdata_start) 开始的 ROM 中提取正确的值。

I'm betting we can't simply use memcpy from ROM on this chip and that we need to do something else to get the initialized values out of ROM and into each TLS block.我敢打赌，我们不能简单地使用该芯片上 ROM 中的 memcpy ，我们需要做一些其他事情来将初始化值从 ROM 中取出并放入每个 TLS 块中。

To check and make sure your fix works, you can try this version of samples/hello_world/src/main.c:要检查并确保您的修复有效，您可以尝试此版本的示例/hello_world/src/main.c：

/*
 * Copyright (c) 2012-2014 Wind River Systems, Inc.
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include <stdio.h>

#define TLS_DATA_VALUE 42

__thread int tls_data_variable = TLS_DATA_VALUE;

int main(void)
{
	if (tls_data_variable == TLS_DATA_VALUE) {
		printf("SUCCESS\n");
	} else {
		printf("FAILURE: tls_data_variable is %d instead of %d\n", tls_data_variable, TLS_DATA_VALUE);
	}
	return 0;
}

For the example code, my test was SUCCESS. For esp32c3, after the bootloader bootstrapping, LOADADDR(__tdata_start) should have been mapped to ADDR(__tdata_start) by the Flash MMU, and the data therein can be accessed normally through ADDR(__tdata_start).

I (62) boot: ESP Simple boot
I (62) boot: compile time May 13 2024 09:29:38
I (62) boot: Multicore bootloader
I (62) spi_flash: detected chip: mxic
I (64) spi_flash: flash io: dio
W (67) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
I (79) boot: chip revision: v0.3
I (82) boot.esp32c3: SPI Speed : 40MHz
I (86) boot.esp32c3: SPI Mode : SLOW READ
I (90) boot.esp32c3: SPI Flash Size : 4MB
I (94) boot: Enabling RNG early entropy source...
[esp32c3] [INF] DRAM: lma 0x00000020 vma 0x3fc87a30 len 0xb48 (2888)
[esp32c3] [INF] DRAM: lma 0x00000b70 vma 0x3fc88578 len 0xa44 (2628)
[esp32c3] [INF] IRAM: lma 0x000015bc vma 0x40380000 len 0x6b34 (27444)
[esp32c3] [INF] IRAM: lma 0x000080f8 vma 0x40386b34 len 0xeec (3820)
[esp32c3] [INF] padd: lma 0x00008ff8 vma 0x00000000 len 0x7000 (28672)
[esp32c3] [INF] IMAP: lma 0x00010000 vma 0x42010000 len 0x2fb8 (12216)
[esp32c3] [INF] padd: lma 0x00012fc0 vma 0x00000000 len 0xd038 (53304)
[esp32c3] [INF] DMAP: lma 0x00020000 vma 0x3c000000 len 0x7a8 (1960)
[esp32c3] [INF] Image with 8 segments
[esp32c3] [INF] DROM segment: paddr=00020000h, vaddr=3c000000h, size=007B0h ( 1968) map
[esp32c3] [INF] IROM segment: paddr=00010000h, vaddr=42010000h, size=02FB8h ( 12216) map
*** Booting Zephyr OS build v3.6.0-3667-gf4c067c6bcf0 ***
SUCCESS

[sylvioalves]

@lgl88911 Thanks for testing and confirming it works. I've tested already before submitting this PR to confirm same scenario. @keith-packard I'll check similar entries as such as the __tdata_start to make sure this SoC is properly handling it. Anyway, let me know if you have any other comment or suggestion. Thanks!