Enable 128K virtual memory via external SPI SRAM

[earlephilhower]

--edit--

This is at a state where it's working well and there is a reasonable API for users with a 23LC1024 SRAM wired up. The virtualmem example shows all the calls that are required.

Theory of Operation:

The Xtensa core generates a hardware exception (unrelated to C++ exceptions) when an address that's defined as invalid for load or store. The XTOS ROM routines capture the machine state and call a standard C exception handler routine (or the default one which resets the system).

We hook into this exception callback and decode the EXCVADDR (the address being accessed) and use the exception PC to read out the faulting instruction. We decode that instruction and simulate it's behavior (i.e. either loading or storing some data to a register/external memory) and then return to the calling application.

We use the hardware SPI interface to talk to an external SRAM/PSRAM, and implement a simple cache to minimize the amount of times we actually need to go out over the (slow) SPI bus. The SPI is set up in a DIO mode which uses no more pins than normal SPI, but provides for ~2X faster transfers.

NOTE: This works fine for processor accesses, but cannot be used by any of the peripherals' DMA. For that, we'd need a real MMU.

Hardware Configuration (make sure you have 3.3V compatible SRAMs):

• SPI interfaced byte-addressible SRAM/PSRAM: 23LC1024 or smaller
  CS -> GPIO15
  SCK -> GPIO14
  MOSI -> GPIO13
  MISO -> GPIO12
  (note these are GPIO numbers, not the Arduion Dxx ones. Refer to your ESP8266 board schematic for the mapping of GPIO to pin.)
• Higher density PSRAM (ESP-PSRAM64H/etc.) should work as well, but I'm still waiting on my chips so haven't done any testing. Biggest concern is their command set and functionality in DIO mode. If DIO mode isn't supported, then a fallback to SIO or moving to QIO is a possibility.

This is still a WIP, but the base handler is functional.
Using an exception handler that hooks into the invalid read/write address hardware exception, capture reads to 256MB starting at 0x1000_0000 and (eventually) map that into a SW managed cache in front of an external SPI SRAM.
This RAM will be slower than internal RAM since it is SW managed, but should accessible for use by all apps and the OS without any special concerns. Don't expect to use this RAM in ISRs or time critical sections.
The code now captures the read and write exceptions and continues operations, but the SPI SRAM read/write and the cache management is not in there yet. I need to dig out my SPI SRAM and hook it up to give it a try.
Based off of the PROGMEM misaligned exception handler.

[earlephilhower]

Example virtalmem.ino output. 126K free is nice. :)

Internal buffer: Address 0x3ffef5f4, free 47624
External buffer: Address 0x1000000c, free 126960
Virtual Memory Write:   453518 cycles for 4K
Physical Memory Write:  7170 cycles for 4K
Virtual Memory Read:   415573 cycles for 4K (sum 0aaaaa00)
Physical Memory Read:  7176 cycles for 4K (sum 0aaaaa00)
Virtual Memory Write:   355935 cycles for 2K by 16
Physical Memory Write:  7170 cycles for 2K by 16
Virtual Memory Read:   335255 cycles for 2K by 16 (sum 01baaa00)
Physical Memory Read:  7176 cycles for 2K by 16 (sum 01baaa00)
Virtual Memory Write:   294015 cycles for 1K by 8
Physical Memory Write:  7170 cycles for 1K by 8
Virtual Memory Read:   287921 cycles for 1K by 8 (sum 0001fe00)
Physical Memory Read:  7171 cycles for 1K by 8 (sum 0001fe00)
Internal free: 47624
External free: 126648
String: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
Internal free: 51728
External free: 130752

[s-hadinger]

Earle, I have a question loosely coupled to this PR.

Would it be possible to use a similar trick to read data in Flash beyond the 1MB limit, without explicit SPI command, or even better, run code beyond the 1MB limit. I understand the performance hit, but there may be some scenarios for rarely used code or data.

[earlephilhower]

This method won't work for code in PMEM, but it's possible to use this idea to do data reads from outside of PMEM. This only catches load or store exceptions, not ifetch ones. I don't think ifetch exceptions are exposed.

[earlephilhower]

Thanks for the reminder, @mhightower83 ! I've pulled out the common ASM block so your debugged one will be used in the VM subsystem as well as the non32xfer one.

[devyte]

LGTM, nothing jumps out.

[dok-net]

@earlephilhower There are ICACHE_RAM_ATTRs in this PR.

[david-vfortified]

Hello,
Is it possible to store global variables in external SPI RAM?