Linker script needs simplification

[projectgus]

Mentioned by @foogod in #24 & #35, but it's been on my mind as well.

There's at least 3 contributing factors I know of:

• esp arch has a lot of memory types and spi flash size variations.
• The SDK libraries do things in a way which is incompatible with upstream code unless you want to put an attribute on nearly every function, so need special cases for SDK vs non-SDK .text sections and similar.
• That linker script has been hacked up from the RTOS SDK one instead of starting from scratch, and I think the RTOS SDK one was hacked up from an Xtensa boilerplate one. so there's at least some cruft.

The last part is something that can be easily fixed with a clean up pass to remove the cruft.

The one thing I don't want to do is make the linker script less complex by preprocessing libraries with objcopy (any more than we already have to!). That just moves the complexity around.

The other significant change with the current linker script is running it through the C preprocessor to pick up things like flash size. This is a kind of "lesser of two evils" thing in my mind, compared to the Espressif solution of having multiple linker scripts. There might be a better way though, possibly using two linker scripts so the flash-specific parts go in a smaller script and then there's a longer generic script with the rest...

Thoughts/suggestions welcome.

[DagAgren]

Is there really a need for the multiple linker scripts? Can't you just link with the biggest size, and if it doesn't fit in a smaller one, it doesn't fit?

[projectgus]

That's a fair question. Unlike the Espressif SDK, we don't really have "multiple" linker scripts - we have one linker script and we run it through the C preprocessor to set the flash size:
https://github.com/SuperHouse/esp-open-rtos/blob/master/ld/eagle.app.v6.ld#L37

... do we need to do this at all? Maybe not. The only hard technical reason I can think of is that the Espressif binary SDK uses the last sector of the flash to store configuration data, so it is possible on <8Mbit targets to have an image that just fits into flash but breaks subtly when the internal WiFi configuration auto-updates itself. However, I just realised we don't account for that sector when calculating IROM0_LEN anyhow - so that's either a bug to be fixed or an unnecessary feature to be removed entirely.

(The SDK behaviour does mean that you have to know the flash size when you flash, as it gets written into the configuration block at the beginning of flash and used by the SDK to find the last sector. Pretty soon we will have the ability to change the behaviour ourselves so esp-open-rtos does it differently, if we wanted to.)

The less technical reason, from my perspective, is that it can be helpful to get an error message at compile time when your program won't fit in flash, rather than getting (potentially) weird errors when you try to flash it (esptool just says "failed to enter flash download mode" if the file is too big for the flash).