what does 'drom_seg overflowed' mean?

[yanshay]

I'm working on some app, and suddenly today after adding a bit of code the linker errored with:

/Users/yanshay/.rustup/toolchains/esp/xtensa-esp-elf/esp-14.2.0_20240906/xtensa-esp-elf/bin/../lib/gcc/xtensa-esp-elf/14.2.0/../../../../xtensa-esp-elf/bin/ld: /Users/yanshay/ProgProj/ESP32/hamster/spoolease-os/device/target/xtensa-esp32s3-none-elf/release/deps/SpoolEase-25fec2ce5f509da7 section `.rodata.wifi' will not fit in region `drom_seg'
          /Users/yanshay/.rustup/toolchains/esp/xtensa-esp-elf/esp-14.2.0_20240906/xtensa-esp-elf/bin/../lib/gcc/xtensa-esp-elf/14.2.0/../../../../xtensa-esp-elf/bin/ld: region `drom_seg' overflowed by 23368 bytes
          collect2: error: ld returned 1 exit status

What does it mean?
I'm nowhere near the size of the partition available for code (saying that because it says rom).
Is there some limitation on something?

[bjoernQ]

Yes It's flash mapped into memory

I guess it's ESP32-S3? Indeed, we define it too small:

esp-hal/esp-hal/ld/esp32s3/memory.x

Lines 37 to 38 in a1cc34f

	irom_seg ( RX ) : ORIGIN = 0x42000020, len = 4M - 0x20
	drom_seg ( R ) : ORIGIN = 0x3C000020, len = 4M - 0x20

vs

[yanshay]

What I did is copy memory.x from esp-Hal to my project root and increase the drom_seg to the size of the partition, is that ok? No MMU size limit or something else to consider?

Also, why did the drom_seg overflow? The total image is about 4MB but that's both code and data and my understanding code goes to
irom_seg and data to drom_seg, so neither should reach 4MB and code would get there first.

[bjoernQ]

That sounds good. (and also PSRAM counts in here - so if we would map 32mb of flash we won't be able to map additional PSRAM)

It's really the same limit applied to drom + iram - see

esp-hal/esp-hal/ld/esp32s3/esp32s3.x

Lines 12 to 40 in 0876bac

	SECTIONS {
	.rotext_dummy (NOLOAD) :
	{
	/* This dummy section represents the .rodata section within ROTEXT.
	* Since the same physical memory is mapped to both DROM and IROM,
	* we need to make sure the .rodata and .text sections don't overlap.
	* We skip the amount of memory taken by .rodata* in .text
	*/
	/* Start at the same alignment constraint than .flash.text */
	. = ALIGN(ALIGNOF(.rodata));
	. = ALIGN(ALIGNOF(.rodata.wifi));
	/* Create an empty gap as big as .text section */
	. = . + SIZEOF(.rodata_desc);
	. = . + SIZEOF(.rodata);
	. = . + SIZEOF(.rodata.wifi);
	/* Prepare the alignment of the section above. Few bytes (0x20) must be
	* added for the mapping header.
	*/
	. = ALIGN(0x10000) + 0x20;
	_rotext_reserved_start = .;
	} > ROTEXT
	}
	INSERT BEFORE .text;

And there is also this padding:

esp-hal/esp-hal/ld/esp32s3/esp32s3.x

Line 36 in 0876bac

. = ALIGN(0x10000) + 0x20;

Actually, the same flash memory is available through both busses

[yanshay]

It's really the same limit applied to drom + iram

I was referring to irom, not iram. My understaning is that my code eventually splits into code (irom) and data (drom). But the drom size is the issue and that's surely not over 4MB.
So the same 4MB data is mapped to two addresses at the same time (irom_seg and drom_seg)?
I increased only the drom_seg and it was enough to compile, the irom is still on 4MB.

If I understand correctly, doesn't it waste address space?
If the total limit is 32MB of address space as I understand from your answer, then that could be an issue if someone wants to use the full 16MB for code+data (and then 16MB for irom, and same 16MB for drom) and then also wants to use PSRAM but 2x16MB would use the entire 32MB which I understand from your text is mappable.

Maybe it requires too deep understanding of compiler/linker that I don't have. I'm not close to these limits anyway in the visible future, but I can see that happening if some large data file is required to be placed into flash.

[bjoernQ]

typo: drom + irom

So the same 4MB data is mapped to two addresses at the same time (irom_seg and drom_seg)?

Yes that is the case