мерси, видях го но не ми върши рабта...

некак си го излъгах
https://www.youtube.com/watch?v=SdpsmgRp5Co

как се превежда това за "човешки" GCC линкер



и тва парче "мръвка" да иде там на рам адрес 0x2000010C
uint32_t RAM_MAC_BASE_ADDR[ROM_RAM_TABLE_SIZE] __attribute__((section(".data:RAM_MAC_BASE_ADDR")));

трябва да го напасна с това

Мисля, че не разбирам въпроса... нито какви са тия "човешки" линкери...

Но ако не греша искаш някаква табличка да се прехвърли на адрес 0x2000010C като част от статичната инициализация?

Ако е така, просто си правиш оутпут секция и я описваш в MEMORY по същия начин, както ти е описана .data, само че на адреса който искаш. Иначе пак да се пише във флаша...
Въпросът е, че кодът който ти прави статичната инициализация също трябва да е наясно с това, че освен да инициализира .data ще трябва да инициализира и новата секция. Демек ще трябва да го пипнеш... освен ако двете секции не са съседни.

Не знам каква е целта и струва ли си подобна заигравка с линкера, като същото може да си го направиш и с код, който в началото прави едно memcopy((void*)0x2000010C, table, sizeof(table))....

опитвам се да портна TI Z-Stack ( Zigbee ) за GCC ... такова е мазало че не е истина просто
та да си "защитат" сорса ( Open ) да работи само на техни чипове са записали част от библиотеката в ROM-ма ( сорс няма )
и инициализират няколко таблици func & ram ... и едната е рам масив на фиксиран адрес ... точно по средата на .data
TI ползват CCS и/или clang някъв компилатор и .data : RAM_MAC_BASE_ADDR : LOAD > 0x2000010C е от него
но не се приема от GCC

направих една щуротия и взе че тръгна - ма незнам дали е "правилно"

Абе то може да е "правилно", ама не в смисъла в който искаш

Значи адрес може да се задава само на output секция, като я сложиш в даден регион. Поне аз не знам за други варианти. Освен това секциите ти не могат да се застъпват.
Така че вариантите са:
1) Правиш отделни секции за нещата преди 0x2000010C, после секция за таблицата и после секция за оставащия РАМ.
2) Ползваш си само една (data) но се грижиш така да наредиш input секциите, че таблицата да дойде на адреса, който искаш.

Обикновено втория вариант е кофти, но в случая имаш само около 270 байта преди таблицата, така че можеш или да ги прежалиш или да ги заемеш с нещо до тоя размер. За целта просто трябва да изконсумираш някак си тая дупка, после да сложиш таблицата и после vtable и останалите input секции.

ще видя дали няма нещо друго фиксирано [ 270 ] ...

TI имат друго виждане за линкер скриптовете. Макар, че донякъде наподобяват GNU. (линкера е част от binutils, не е част от GCC.)
Но пък TI имат и документация където е описано кое, как за техния линкер.
Иначе един ден проба-грешка, ще ти спестят час четене на документацията.

може... но ако исках TI, щях да зареда тяхната среда, а в момента целта ми е друга ( GCC - PlatformIO - Arduino )

Сетих се, че най-вероятно резервират първите 256 байта за вектор таблицата. Провери дали пренасочват прекъсванията в РАМ. И да не пренасочват пак най-вероятно са я запазили тая област, така че нещата се опростяват. Просто в началото на дата секцията си слагаш векторите, после тая таблица и после всичко останало...

ld от GNU binutils също имат документация. Публично достъпна. И рядко илизат нови версии. Ако въобще нещо се променя там.
Адресът в RAM-а обикновено е закован. В простите и най-често използвани варианти на .data изходна секция които съм виждал. И както Миро каза, дърводелеца който го кове осигурява този адрес да е в съответния MEMORY region. И този region да не се застъпва с други региони и секциите в тях.

да де ама питах дали GCC (линкер скрипт ) има еквивалент на



оная магария дето я направих "работи" .... *(.RAM_MAC_BASE_ADDR*)
просто незнам дали е правилна ( без да криетвам допълнителни региони )

по принцип мога да едитна масива с атрибут @ адрес 0x2000010C .... но гледам да не барам оригиналния код ... само им оправих "индийските грешки"

БТВ: в последствие ТИ "супорта" каза че ЗиСтека е oграничен САМО до TIRTOS ... ама рекламират nortos и FreeRtos .... пеераси сър
супорт е в кавички - тикет вика: ходи във форума, форума вика реви на ФАЕ, ФАЕ ме праща на тикет ..... параграф XXL

btw - мойто е грешно ... една библиотека го прави "правилно" и е компилирана с цланг
блах...

по принцип използвам printf за дебъг и вместо да интегрирам разни олекотени версии използвам компилаторския stdio в нано режим
порта му е няколко "празни" system calls ( open, close ... etc ) и ретаргет на UART към _write_r() ... загубата е ~9k флаш и ~2к рам ... приемливо за дебъг

АРМ М4 бареметал - пушка, обаче закача ли FreeRTOS - принт без "\n" автоматично влиза в block mode макар,
че изрично има setvbuf(stdout, NULL, _IONBF, 0);
кода на сискол порта е един и същ - разликата е malloc/free пренасочени към FreeRTOS
някъде ртос-а прецаква нящо и ... чака "\n" ... ако не дойде - отпечатва буфера когато се напълни
интересното е че като оставя malloc_r / free_r работи както се очаква
ако ги пренасоча към malloc/free ... "блокира"
тези REENT malloc_r / free_r използват дефол heap без проблем със sbrk return -1
демек FreeRTOS бара нещо в REENT а код за това няма
при опит да портна TIRTOS за М4 - същия ефект...
докато при M0 куртексите този ефект го няма като версията на GCC е една и съща
питанката е кое е това "животно" дето блокира stdio за "\n" или защо флаговете setvbuf се игнорират или или ...

намерих го ... майка му и мечка

configUSE_NEWLIB_REENTRANT = 1 прави
_impure_ptr = &( pxCurrentTCB->xNewLib_reent );