ESP32 Forum

Is it possible to use PSRAM instead of flash chip? I mean executing code from PSRAM mapped on 0x400C2000 area.
From datasheets, it seems that read instruction codes are matching.

Of course there has to be a way to load code into PSRAM. This leads to my second question.

Is it possible to boot code from real flash (specified by fuses, or default), then at some point temporarily change flash pinout to use other flash chip (in my case PSRAM)?

My idea is to use SDIO for SD card. SD card would hold many firmware images which you can pick and "run" - by copying it into PSRAM as "fake" flash chip.
This of course implies custom SDIO "bootloader" menu, which would run from real flash.

kgsws_cz wrote:Is it possible to use PSRAM instead of flash chip? I mean executing code from PSRAM mapped on 0x400C2000 area.
From datasheets, it seems that read instruction codes are matching.

Of course there has to be a way to load code into PSRAM. This leads to my second question.

Is it possible to boot code from real flash (specified by fuses, or default), then at some point temporarily change flash pinout to use other flash chip (in my case PSRAM)?

My idea is to use SDIO for SD card. SD card would hold many firmware images which you can pick and "run" - by copying it into PSRAM as "fake" flash chip.
This of course implies custom SDIO "bootloader" menu, which would run from real flash.

You can try "OTA" over serial channel, this should work. ESP gets data in SD and save in specific OTA partition and reboot.

I did ask this several times before with no definitive answer

https://esp32.com/viewtopic.php?f=2&t=6277
https://esp32.com/viewtopic.php?f=2&t=6245

I think you could modify the bootloading code to read SD into mem and asm jump to spi ram
That's how PCs do that using mass media storage like CD,USB,HD etc.
Check esptool.py - it has bootloader stubs in binary but im not sure if encrypted
Maybe ask guys here who wrote that tool for help - I think Mr Kolban would help here a lot - he was able to writhe image to flash with node.js

Oooh ... I love puzzles like this!! Ive done quite a bit of study on how ESP32 memory management and execution architecture work but so far not turned my attention of PSRAM ... but let's assume that it has the following characteristics (which again ... I have NOT validated):

1. It can be accessed by BOTH executable and data buses.
2. It can be accessed by the ESP32 MMU (Memory Management Unit, the low level component that maps a read or write from an address space to the underlying real storage area ... flash, ROM, embedded RAM, PSRAM).

On the use case however ... If what we want to achieve is booting an ESP32 and selecting an executable from SD card and then running it ... without thinking about PSRAM ... I think we could achieve that today. We would boot the ESP32 into a bootloader that reads the executable you desire from SD card and re-writes flash with the desired app copied from SD. No PSRAM involved and hence more applicability.

Are there other potential reasons for using PSRAM over flash? Is it somehow faster or offer any other qualities over flash?

From datasheet, i strongly suspect that certain memory areas can be read but not executed as a code. But i could be wrong.

I would like to use PSRAM because it is more suitable for constant rewriting. It would be possible to use Flash, but i would really like to avoid it. I want to go that one extra step and use PSRAM instead.
And it still it is not clear whether we can change QSPI pinout, temporarily, to boot from other "flash" (or PSRAM in my case).

There are two questions. I think i can just try first one. Replace Flash with PSRAM containing valid firmware, boot ESP from it and see what happens.

I would still like to know from someone.

My system would be designed like this:
Flash - just for SD card bootloader. Potentially using SoC with integrated 2MB flash.
PSRAM - as a fake flash. 8 or 16 MB, whatever exists.
PSRAM - 4MB as ESP RAM.

Why would you change QSPI pinout? PSRAM is not nand. System must boot from non-volatile memory that has code to boot obviously.
This is all very easy but requires programming custom bootloader - equivalent to boot manager in Windows with choice menu or something.

Mr kgsws_cz,
I read through the technical reference ... section 26.3.2.2 - MMU - External Memory and I think you are correct. It seems that external RAM can only be mapped south of 0x4000 0000 which places it in data bus rather that instruction bus. If this is correct, then we can't seem to map to executable code. It is my understanding that we can't execute instructions unless they are 0x4000 0000 or above.

kolban wrote:Mr kgsws_cz,
I read through the technical reference ... section 26.3.2.2 - MMU - External Memory and I think you are correct. It seems that external RAM can only be mapped south of 0x4000 0000 which places it in data bus rather that instruction bus. If this is correct, then we can't seem to map to executable code. It is my understanding that we can't execute instructions unless they are 0x4000 0000 or above.

Edited!

Actually... technicaly it can be possible, by fiddling with the control wires of the flash, by using external logic to rout the CS of the flash to the PSRAM, therefore 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.

What is needed here is to also try to tweek the driver to use RAM commands not Flash commands, but AFAIK it's hard coded into the ESP internal ROM (not sure how the 2nd stage bootloader uses the drivers though).
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

So CS would kind of switch 'memory bank' to psram?
Execution space is limited by MMU/MPU PIDs mapping virtual adresses to cpu. Question is if we can add psRAM PIDs to that process