PSRAM as Flash

[kgsws_cz]

... tricking the ESP when it tries to access flash, but it's actually tries accessing the RAM chip, which has the running app.
So basically what you would do is, boot from Flash, write SD card binary data into the RAM, modify the flash partition table, and reboot.
Here the RAM voltage should be provided externally to keep content.
Then on reboot the second stage bootloader (with the custom additions as well) will load into the ESP internal RAM, find the starting adress of our code (which will be the starting adress when the external logic scwitches to the RAM), then before booting into that adress it activates external logic, to rerout the CS signal to the RAM, and proceeds to boot into the uses app from external RAM.

This was my point whole time. However i would like to avoid using external logic.
My second question is about QSPI pinout - if it is possible to change it temporarily, to avoid using external logic (re-route CS pin to PSRAM).

... Although it's worth noting that most basic read and write commands are exactly the same, however flash uses different stuff as well as dummy cycles so it's not so easy

This closest to answer for my first question. Thanks.
I would rely on read access to be compatible with PSRAM. I know only basics about SPI flash / PSRAM access. And i noticed that read commands are the same. But i do not know anything about dummy cycles. I do not know what commands does ESP32 use to execute from flash, but i would not need to use any write / erase commands.
Maybe best way to do this would be to just try it. I have access to logic analyser too.

[Vader_Mester]

This was my point whole time. However i would like to avoid using external logic.
My second question is about QSPI pinout - if it is possible to change it temporarily, to avoid using external logic (re-route CS pin to PSRAM).

I don't think it is possible to change the pinout much, some part of it is inside the ESP32 ROM and eFuse registers, which are not changable (only once, but this would loose our point).
However external logic is needed.
A simple circuit would do, with some gates and Flip-Flops, no need for an additional Microcontroller.

[Deouss]

Correct me if I am wrong - so why exactly execution is not possible?
The MPU - memory protection unit would not allow it?
I understand there are a lot of memory mapping tables between interrupts, rom etc so that could cause massive system exceptions
But maybe it is all possible by simply adding some mapping entries somehow - I do not know how thou

[kolban]

Howdy,
My understanding is that the ESP32 utilizes a harvard architecture. This means that there are two buses on the CPU. One which is used to transfer bytes for data and a second bus used to transfer instructions for execution. I also (loosely) understand that in the virtual address space of the ESP32, data that can be accessed south of address 0x4000 0000 is the data bus while data north of that is the instruction bus. From a quick examination of external RAM mapping through the Memory Mapping Unit (MMU), I could only find that external RAM was addressable south of 0x4000 0000. Putting these notions together, this would imply that external RAM can only be accessed through the data bus and not through the instruction bus. From this I deduce that unless information comes through the instruction bus, it can't be executed.

I say all this not with authority but with the hope that if my model is flawed, the community can help me set it straight

[Deouss]

I understand whole addressing is just mapping virtual addresses to physical access with peripheral registers so memory is paged in any way possible for linear addressing by MMU - which has a table of addresses - maybe updatable

[Vader_Mester]

Actually I revisited this idea in the last couple of days by hard digging into the code, and I thing I figured it out.
It's not just hardware but software change as well.

For this to work, you will need a WROVER module, delid the module, and modify the hardware with an external logic (2 Flip-flop and a gate), to rerout the Flash /CS signal to the PSRAM, and to keep the RAM powered during ESP reset.

Here is the flow:
- ESP boots normally from flash, with external PSRAM enabled. All external logic is in default state, meaning that flash and ram should work as default.
- The binary you wish to run from RAM is copied over to PSRAM from an external source, to the appropriate address.
- Once finished a GPIO will trigger the 1st Flip-flop. This will keep the power to the RAM after ESP reset, to keep the data intact.
(note here that the flip-flop's normal output must be routed back to a GPIO to detect the change after reset. Mondatory for the 2nd stage bootloader.)
- Immediatelly after this the ESP chip must be reset.
- After reset ESP boots. New stuff starts hapenning when you land into the 2nd stage bootloader. The 2nd stage bootloader is loaded from flash still, but after it starts running, it checks the gpio to detect the changed flip-flip state.
- After detection the bootloader will trigger the 2nd flip-flop. This will trigger a gate or bus-switch to rerout the flash CS signal to the RAM.
At this point the bootloader will branch away from the standard bootloader procedures to use modified bootloader functions which in fact use SPI RAM access functions instead of the ROM flash code - from this point the ESP is running from the RAM, pretending it's the flash. Bootloader essentially has to do the same (basic hardware initialization, MMU and cache init, and loading the boot image into the ESP).
- At this point your application should be running from the PSRAM and not from the flash.

Based on my research the following is possible:
- The ESP-IDF part seems simple. With some defines (able to set them from Menuconfig), \components\spi_flash\flash_ops.c file can be modified, to replace the esp rom-based flash write and read functions with the same functions for the PSRAM.
(this file just contains IDF function wrappers of the ROM based flash access funtions).
- The bootloader part is difficult though. In the 2nd stage bootloader, all the work is done to access the flash is done using the ROM-code functions, so here, one needs to rewrite the bootloader functions with PSRAM access. The key concern is to not to run out of bootloader program space.

I know this approach is far from ideal, and very time consuming, but so far this is the most possible way as it does use existing IDF stuff.
This could be used for development, as this is eliminates reflashing over and over again keeping your flash chip alive longer - however in this case using NVS would not make sense
Also unplugging the power means you have to reload your app into the RAM again, but that is quick thing if you are using for example an SD card.