user38721: I created the below partition table for an esp32 and replaced the 'default_8MB.csv' with it.
# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0x5000,
otadata,  data, ota,     0xe000,  0x2000,
app0,     app,  ota_0,   0x10000, 0x330000,
app1,     app,  ota_1,   0x340000,0x330000,
eeprom,   data, 0x99,    0x670000,0x1000,
spiffs,   data, spiffs,  0x671000,0x18f000,

After uploading a sketch, I confirmed that the partition table was correctly uploaded to the flash at address 0x8000, using esptool.py --port /dev/ttyACM1 read_flash 0x8000 0x300 partition_table.bin && gen_esp32part.py partition_table.bin && cat partition_table.bin.
Now my question is: what do I have to do so that the EEPROM.h library maps the eeprom emulation to the address that I have specified in the partition table? I naively assumed that EEPROM.h would automatically use the partition named "eeprom", which doesn't seem to be the case.
I uploaded the following test sketch to analyse the situation:
#include <Arduino.h>
#include <EEPROM.h>

String s="this is a unique string";

void setup(){
  EEPROM.begin(1024);

  for (uint32_t i=0;i<s.length();i++){
    EEPROM.write(i,s[i]);
  }
  EEPROM.commit();
  Serial.println("EEPROM stored");
}

void loop() {
  delay(10000);
}

After the sketch has stored my unique string I read the flash memory using esptool and expected to find the string at an offset of 0x670000, but that wasn't the case. Instead it must be stored somewhere else because I can retrieve the string in a different sketch.
One thing that is confusing me: I'm pretty sure that I once ordered ESP-WROOM32s with 4MB flash, but the esptool's auto-flash-detection states that my board has 8MB. Can this flash-detection be trusted or does it simply fail because I try to flash 8MB to a 4MB ESP32? What is supposed to happen if I created a partition table that exceeds the flash memory size? When I put a partition table at an offset of 10M the build process still doesn't fail (is that what should happen?).
My main question: which additional steps do I have to take to get my ESP running with a custom_partion_table.csv (beside creating the table) and when using "EEPROM.h"?

user4143: EEPROM on the ESP32 doesn't work like you would expect.  It uses the SDK's "Non-Volatile Ram" storage system to store the data within the nvs partition.  This works through a system of "Key / Value" pairs, and the data is stored as a "BLOB" (Binary Large OBject) for the key eeprom in the namespace eeprom. 
Quite what the internal layout of the data within the partition itself is I have no clue (the SDK is closed source), but it won't just have your string located at the start of the partition - it will be at the start of the BLOB, wherever that happens to be in the partition.
The eeprom partition is no longer used. It's just wasted space.

Can this flash-detection be trusted or does it simply fail because I try to flash 8MB to a 4MB ESP32?

I can't comment on that I'm afraid. I would have thought it would look at the chip's JEDEC data, but it may just look at the partition table information instead.

What is supposed to happen if I created a partition table that exceeds the flash memory size?

Probably not a lot, since much of the partition table refers to data storage, or a (presently) unused OTA partition.
When you compile your code you're only compiling it for the partition in which it will reside (app0 for example). When you upload the code you are only uploading to that partition.  Anything outside that range is irrelevant to the compilation / uploading.

When I put a partition table at an offset of 10M the build process still doesn't fail (is that what should happen?).

As I mentioned, it won't care. The partition will not be accessible, since it doesn't actually exist, but it's just an entry in a table. The compiler doesn't know or care what it is.

38721: <p>I created the below partition table for an esp32 and replaced the 'default_8MB.csv' with it.</p>

<pre><code># Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0x5000,
otadata,  data, ota,     0xe000,  0x2000,
app0,     app,  ota_0,   0x10000, 0x330000,
app1,     app,  ota_1,   0x340000,0x330000,
eeprom,   data, 0x99,    0x670000,0x1000,
spiffs,   data, spiffs,  0x671000,0x18f000,
</code></pre>

<p>After uploading a sketch, I confirmed that the partition table was correctly uploaded to the flash at address 0x8000, using <code>esptool.py --port /dev/ttyACM1 read_flash 0x8000 0x300 partition_table.bin &amp;&amp; gen_esp32part.py partition_table.bin &amp;&amp; cat partition_table.bin</code>.</p>

<p>Now my question is: what do I have to do so that the <code>EEPROM.h</code> library maps the eeprom emulation to the address that I have specified in the partition table? I naively assumed that <code>EEPROM.h</code> would automatically use the partition named "eeprom", which doesn't seem to be the case.</p>

<p>I uploaded the following test sketch to analyse the situation:</p>

<pre><code>#include &lt;Arduino.h&gt;
#include &lt;EEPROM.h&gt;

String s="this is a unique string";

void setup(){
  EEPROM.begin(1024);

  for (uint32_t i=0;i&lt;s.length();i++){
    EEPROM.write(i,s[i]);
  }
  EEPROM.commit();
  Serial.println("EEPROM stored");
}

void loop() {
  delay(10000);
}
</code></pre>

<p>After the sketch has stored my unique string I read the flash memory using esptool and expected to find the string at an offset of 0x670000, but that wasn't the case. Instead it must be stored somewhere else because I can retrieve the string in a different sketch.</p>

<p>One thing that is confusing me: I'm pretty sure that I once ordered ESP-WROOM32s with 4MB flash, but the esptool's auto-flash-detection states that my board has 8MB. Can this flash-detection be trusted or does it simply fail because I try to flash 8MB to a 4MB ESP32? What is supposed to happen if I created a partition table that exceeds the flash memory size? When I put a partition table at an offset of 10M the build process still doesn't fail (is that what should happen?).</p>

<p>My main question: which additional steps do I have to take to get my ESP running with a custom_partion_table.csv (beside creating the table) and when using "EEPROM.h"?</p>
 4143: <p>EEPROM on the ESP32 doesn't work like you would expect.  It uses the SDK's "Non-Volatile Ram" storage system to store the data within the <code>nvs</code> partition.  This works through a system of "Key / Value" pairs, and the data is stored as a "BLOB" (Binary Large OBject) for the key <code>eeprom</code> in the namespace <code>eeprom</code>. </p>

<p>Quite what the internal layout of the data within the partition itself is I have no clue (the SDK is closed source), but it won't just have your string located at the start of the partition - it will be at the start of the BLOB, wherever that happens to be in the partition.</p>

<p>The <code>eeprom</code> partition is no longer used. It's just wasted space.</p>

<blockquote>
  <p>Can this flash-detection be trusted or does it simply fail because I try to flash 8MB to a 4MB ESP32?</p>
</blockquote>

<p>I can't comment on that I'm afraid. I would have thought it would look at the chip's JEDEC data, but it may just look at the partition table information instead.</p>

<blockquote>
  <p>What is supposed to happen if I created a partition table that exceeds the flash memory size?</p>
</blockquote>

<p>Probably not a lot, since much of the partition table refers to data storage, or a (presently) unused OTA partition.</p>

<p>When you compile your code you're only compiling it for the partition in which it will reside (app0 for example). When you upload the code you are only uploading to that partition.  Anything outside that range is irrelevant to the compilation / uploading.</p>

<blockquote>
  <p>When I put a partition table at an offset of 10M the build process still doesn't fail (is that what should happen?).</p>
</blockquote>

<p>As I mentioned, it won't care. The partition will not be accessible, since it doesn't actually exist, but it's just an entry in a table. The compiler doesn't know or care what it is.</p>
