Add linker script for external ram

[Volkalex28]

Thank you!

Thank you for your contribution.
Please make sure that your submission includes the following:

Must

• The code compiles without errors or warnings.
• All examples work.
• cargo fmt was run.
• Your changes were added to the CHANGELOG.md in the proper section.
• You updated existing examples or added examples (if applicable).
• Added examples are checked in CI

Nice to have

• You add a description of your work to this PR.
• You added proper docs for your newly added features and code.

[Volkalex28]

Added linker scripts and bss reset for S3. I don’t know how correctly I did it, but all the addresses matched and it started for me

@bjoernQ Please take a look and tell me your opinion. I will be glad for any help

[bjoernQ]

I don't think we should have that +0x20 here - it's used for mapped flash

  /**
   * (0x20 offset above is a convenience for the app binary image generation.
   * Flash cache has 64KB pages. The .bin file which is flashed to the chip
   * has a 0x18 byte file header, and each segment has a 0x08 byte segment
   * header. Setting this offset makes it simple to meet the flash cache MMU's
   * constraint that (paddr % 64KB == vaddr % 64KB).)
   */

[bjoernQ]

I don't think we need this dummy section

[bjoernQ]

To support .data in ext-ram we would need a way to copy the initial data here

[Volkalex28]

Yes, I know. I just want to first understand if I took everything into account for bss, at least 😅

[bjoernQ]

Probably having a way to place uninitialized and zeroed data in PSRAM would require us to initialize PSRAM before calling user's main function

If a user would (by accident) try to use data placed there before initializing PSRAM things will fail in pretty bad ways. Would probably get even worse when we add a way to place initialized data into PSRAM

Maybe it would be even slightly more convenient if the HAL would initialize PSRAM automatically

[Volkalex28]

In general I agree with this. I suggest doing this either at the end of ESP32Reset or in _post_init. I think the first option is better.
But then two questions arise:

• Should we give the user peripherals to the psram
• What to do with printing information about the psram. It is sent via a logger with the log feature, the caller is initialized by the user

[Volkalex28]

Well, after a little research I determined that dummy and offset were needed. Without them, we cannot calculate the correct offset for the psram and, therefore, the placement of data in its segments

[bjoernQ]

Well, after a little research I determined that dummy and offset were needed. Without them, we cannot calculate the correct offset for the psram and, therefore, the placement of data in its segments

Ah ok ... maybe I misread the esp-idf linker scripts

[bjoernQ]

In general I agree with this. I suggest doing this either at the end of ESP32Reset or in _post_init. I think the first option is better. But then two questions arise:

I'd say post_init where we also disable the watchdog timers - we already have "per SOC" code there where this might be a good fit (since we only want it on ESP32, ESP32-S2 and ESP32-S3 for now)

• Should we give the user peripherals to the psram

Probably not. It's just a virtual peripheral and of no use if we initialize the PSRAM before main - we should probably remove the virtual peripheral completely (

esp-hal/esp-hal-common/src/soc/esp32s3/peripherals.rs

Line 87 in 0e927d2

PSRAM <= virtual,

)

• What to do with printing information about the psram. It is sent via a logger with the log feature, the caller is initialized by the user

True - while not ideal we could just remove the logs and keep the information somewhere for the user to query and log themselves - if something goes terribly wrong during initialization, we'll panic with some (hopefully) helpful information anyway

[Volkalex28]

How about giving the user a pre_main function. Call post_init at the end.
It turns out that in post_init we initialize the psram (+bss +data), call pre_main (the user can initiate the logger there), and then print information about the psram

[bjoernQ]

Not really sure if it's worth the effort. Since we basically would need to "remember" all the things from the initialization in both scenarios we can also give the user a way to log things if they want later. I guess it's pretty similar but the "pre_main" thing would be something new to learn for the user

[MabezDev]

Anything we can do to move this PR along? It would be nice to "statically" load some things into PSRAM at boot time.

[jessebraham]

Given the lack of activity here I'm going to go ahead and close this PR for the time being. Thank you for your contribution regardless, I hope somebody can pick this up some time and wrap it up.

If you plan to continue work on this, please feel free to reopen the PR or create a new one.