Создатель frankenstein'a в треде, сейчас будем критиковать ;)
Начнем с карты памяти, ибо указанная автором разбивка частично «предложенная Espressif организация памяти», которую я не могу считать удачной.
1. 40000000h — 4000FFFFh — Это масочное ПЗУ, заложенное при производстве чипа. Сюда нам ничего нельзя загрузить. В принципе. Оттуда можно только дернуть некоторые функции, адреса которых захардкожены в ld файлике из SDK. Скорость работы кода оттуда должна быть сравнима с работой из RAM.
2. 0x3FFE8000 — 0x3fffc000 — RAM. Для данных. Я не проверял может ли процессор делать оттуда фетч инструкций. Здесь у нас статические переменные (bss), .data и ВНЕЗАПНО .rodata. По каким-то причинам все начинает рандомно разваливаться (по крайней мере так было на 0.9.2 SDK), если попытаться переложить rodata в irom0_0, что на первый взгляд кажется логичным решением.
3. 0x40100000 — 0x40107FFF (насколько помню — именно 32k!) IRAM. Оперативная память с фетчем инструкций. Сюда кладется .text и .text.literal.Отсюда должна быть максимальная скорость исполнения кода. Cюда кладутся важные куски из блобов Espressif'а.
4. 0x40200000 — С этого адреса начинается линейный мэппинг всей SPI флешки. (aka irom0) Отсюда можно исполнять код, есть кеш инструкций неизвестного размера. Все, что не влезает в IRAM кладется сюда. Скорость исполнения отсюда в worst-case случае ниже чем из IRAM
То, как это все будет разложено задается ld файлом, и то что навязывает Espressif — не закон.
Благодаря такой «чудной» организации Espressif контузили lwip добавив к каждой функции ICACHE_FLASH_ATTR, который по сути кладет ф-цию в секцию .irom0.text и .irom0.literal.
Так как контузить свой код ICACHE_FLASH_ATTR'ами не хочется — я сделал вот такой вот хак.
Фактически, чтобы не добавлять ICACHE_FLASH_ATTR'ы мы
переименоввываем в собранных .o секции .text -> .irom0.text и .literal -> .irom0.literal.
Шаманство по ссылке сложнее, так как учитывает случай с -ffunction-sections и -gc-sections, когда у нас каждая функция в своей секции.
Соответственно, если хотим использовать newlib полноценно, то его тоже надо релоцировать в irom0, iram не резиновый. esp-open-sdk специально готовит нам irom версию libc. Линковаться надо только с -lcirom вместо -lc.
Начнем с карты памяти, ибо указанная автором разбивка частично «предложенная Espressif организация памяти», которую я не могу считать удачной.
1. 40000000h — 4000FFFFh — Это масочное ПЗУ, заложенное при производстве чипа. Сюда нам ничего нельзя загрузить. В принципе. Оттуда можно только дернуть некоторые функции, адреса которых захардкожены в ld файлике из SDK. Скорость работы кода оттуда должна быть сравнима с работой из RAM.
2. 0x3FFE8000 — 0x3fffc000 — RAM. Для данных. Я не проверял может ли процессор делать оттуда фетч инструкций. Здесь у нас статические переменные (bss), .data и ВНЕЗАПНО .rodata. По каким-то причинам все начинает рандомно разваливаться (по крайней мере так было на 0.9.2 SDK), если попытаться переложить rodata в irom0_0, что на первый взгляд кажется логичным решением.
3. 0x40100000 — 0x40107FFF (насколько помню — именно 32k!) IRAM. Оперативная память с фетчем инструкций. Сюда кладется .text и .text.literal.Отсюда должна быть максимальная скорость исполнения кода. Cюда кладутся важные куски из блобов Espressif'а.
4. 0x40200000 — С этого адреса начинается линейный мэппинг всей SPI флешки. (aka irom0) Отсюда можно исполнять код, есть кеш инструкций неизвестного размера. Все, что не влезает в IRAM кладется сюда. Скорость исполнения отсюда в worst-case случае ниже чем из IRAM
То, как это все будет разложено задается ld файлом, и то что навязывает Espressif — не закон.
Благодаря такой «чудной» организации Espressif контузили lwip добавив к каждой функции ICACHE_FLASH_ATTR, который по сути кладет ф-цию в секцию .irom0.text и .irom0.literal.
Так как контузить свой код ICACHE_FLASH_ATTR'ами не хочется — я сделал вот такой вот хак.
Фактически, чтобы не добавлять ICACHE_FLASH_ATTR'ы мы
переименоввываем в собранных .o секции .text -> .irom0.text и .literal -> .irom0.literal.
Шаманство по ссылке сложнее, так как учитывает случай с -ffunction-sections и -gc-sections, когда у нас каждая функция в своей секции.
Соответственно, если хотим использовать newlib полноценно, то его тоже надо релоцировать в irom0, iram не резиновый. esp-open-sdk специально готовит нам irom версию libc. Линковаться надо только с -lcirom вместо -lc.
А вообще ждем полноценного реверс-инженеринга Espressif'овских блобов. В комментариях к их SDK они писали, что не открывают код, т.к. бояться что «people will make device that bring havoc to wireless networks» ©. А это значит, что там есть много любопытных сокрытых возможностей.