# lib(subdirectory_name).a in the build directory. This behaviour is entirely configurable,
# please read the esp-idf build system document if you need to do this.
#
+-include $(PROJECT_PATH)/build/include/config/auto.conf
LIBS := crypto core net80211 phy rtc pp wpa wps
+ifeq ($(CONFIG_MEMMAP_BT),y)
+ ifeq ($(CONFIG_MEMMAP_TRACEMEM),y)
+ LINKER_SCRIPTS = -T esp32.bt.trace.ld
+ else
+ LINKER_SCRIPTS = -T esp32.bt.ld
+ endif
+else
+ ifeq ($(CONFIG_MEMMAP_TRACEMEM),y)
+ LINKER_SCRIPTS = -T esp32.trace.ld
+ else
+ LINKER_SCRIPTS = -T esp32.ld
+ endif
+endif
+
+LINKER_SCRIPTS += -T esp32.common.ld -T esp32.rom.ld
+
COMPONENT_ADD_LDFLAGS := -lesp32 \
$(abspath libhal.a) \
-L$(abspath lib) \
$(addprefix -l,$(LIBS)) \
-L $(abspath ld) \
- -T eagle.fpga32.v7.ld \
- -T eagle.fpga32.rom.addr.v7.ld
+ $(LINKER_SCRIPTS)
include $(IDF_PATH)/make/component.mk
--- /dev/null
+/* THESE ARE THE VIRTUAL RUNTIME ADDRESSES */
+/* The load addresses are defined later using the AT statements. */
+MEMORY
+{
+ /* All these values assume the flash cache is on, and have the blocks this uses subtracted from the length
+ of the various regions. The 'data access port' dram/drom regions map to the same iram/irom regions but
+ are connected to the data port of the CPU and eg allow bytewise access. */
+ iram0_0_seg (RX) : org = 0x40080000, len = 0x20000 /* IRAM for PRO cpu. Not sure if happy with this, this is MMU area... */
+ iram0_2_seg (RX) : org = 0x400D0018, len = 0x330000 /* Even though the segment name is iram, it is actually mapped to flash */
+ dram0_0_seg (RW) : org = 0x3FFC0000, len = 0x40000 /* Shared RAM, minus rom bss/data/stack.*/
+ drom0_0_seg (R) : org = 0x3F400010, len = 0x800000
+}
+
+_heap_end = 0x40000000;
--- /dev/null
+/* THESE ARE THE VIRTUAL RUNTIME ADDRESSES */
+/* The load addresses are defined later using the AT statements. */
+MEMORY
+{
+ /* All these values assume the flash cache is on, and have the blocks this uses subtracted from the length
+ of the various regions. The 'data access port' dram/drom regions map to the same iram/irom regions but
+ are connected to the data port of the CPU and eg allow bytewise access. */
+ iram0_0_seg (RX) : org = 0x40080000, len = 0x20000 /* IRAM for PRO cpu. Not sure if happy with this, this is MMU area... */
+ iram0_2_seg (RX) : org = 0x400D0018, len = 0x330000 /* Even though the segment name is iram, it is actually mapped to flash */
+ dram0_0_seg (RW) : org = 0x3FFC0000, len = 0x38000 /* Shared RAM, minus rom bss/data/stack.*/
+ drom0_0_seg (R) : org = 0x3F400010, len = 0x800000
+}
+
+_heap_end = 0x3FFF8000;
--- /dev/null
+/* THESE ARE THE VIRTUAL RUNTIME ADDRESSES */
+/* The load addresses are defined later using the AT statements. */
+MEMORY
+{
+ /* All these values assume the flash cache is on, and have the blocks this uses subtracted from the length
+ of the various regions. The 'data access port' dram/drom regions map to the same iram/irom regions but
+ are connected to the data port of the CPU and eg allow bytewise access. */
+ iram0_0_seg (RX) : org = 0x40080000, len = 0x20000 /* IRAM for PRO cpu. Not sure if happy with this, this is MMU area... */
+ iram0_2_seg (RX) : org = 0x400D0018, len = 0x330000 /* Even though the segment name is iram, it is actually mapped to flash */
+ dram0_0_seg (RW) : org = 0x3FFB0000, len = 0x48000 /* Shared RAM, minus rom bss/data/stack.*/
+ drom0_0_seg (R) : org = 0x3F400010, len = 0x800000
+}
+
+_heap_end = 0x3FFF8000;