espidf function to find address for boot firmware is wrong

[Jason2866]

The function will always return the fallback value for the firmware offset

def get_app_partition_offset(pt_table, pt_offset):
    # Get the default boot partition offset
    app_params = get_partition_info(pt_table, pt_offset, {"name": "boot"})
    return app_params.get("offset", "0x10000")

There is no entry boot regarding the documentation https://docs.espressif.com/projects/esp-idf/en/v5.5/esp32/api-guides/partition-tables.html and looking into the predefined standard partitions.csv https://github.com/tasmota/esp-idf/tree/release/v5.5/components/partition_table

changing to:

def get_partition_info(pt_path, pt_offset, pt_params):
    if not os.path.isfile(pt_path):
        sys.stderr.write(
            "Missing partition table file `%s`\n" % pt_path
        )
        env.Exit(1)

    cmd = [
        get_python_exe(),
        os.path.join(FRAMEWORK_DIR, "components", "partition_table", "parttool.py"),
        "-q",
        "--partition-table-offset",
        hex(pt_offset),
        "--partition-table-file",
        pt_path,
        "get_partition_info",
        "--info",
        "size",
        "offset",
    ]

    if pt_params.get("name") == "boot":
        cmd.append("--partition-boot-default")
    else:
        cmd.extend(
            [
                "--partition-type",
                pt_params["type"],
                "--partition-subtype",
                pt_params["subtype"],
            ]
        )

    result = exec_command(cmd)
    if result["returncode"] != 0:
        sys.stderr.write(
            "Couldn't extract information for %s/%s from the partition table\n"
            % (pt_params["type"], pt_params["subtype"])
        )
        sys.stderr.write(result["out"] + "\n")
        sys.stderr.write(result["err"] + "\n")
        env.Exit(1)

    size = offset = 0
    if result["out"].strip():
        size, offset = result["out"].strip().split(" ", 1)

    return {"size": size, "offset": offset}


def get_app_partition_offset(pt_table, pt_offset):
    # Get the default boot partition offset
    ota_app_params = get_partition_info(pt_table, pt_offset, {"type": "app", "subtype": "ota_0"})
    if ota_app_params.get("offset"):
        return ota_app_params["offset"]
    factory_app_params = get_partition_info(pt_table, pt_offset, {"type": "app", "subtype": "factory"})
    return factory_app_params.get("offset", "0x10000")

does bring the expected results

[valeros]

Hi @Jason2866, can you put together a simple project to reproduce the problem?

IIRC, in that case boot isn’t a partition name but a flag that triggers passing --partition-boot-default to parttool.py, which returns the correct offset.

[Jason2866]

@valeros A simple blink will do with this partition scheme.

# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0x5000,
otadata,  data, ota,     0xe000,  0x2000,
safeboot, app,  factory, 0x10000, 0xD0000,
app0,     app,  ota_0,   0xE0000, 0x2D0000,
spiffs,   data, spiffs,  0x3B0000,0x50000,

Instead of starting from the ota_0 slot the factory fallback firmware is detected and gets started.
As described in espressif docs factory is a fallback firmware and should only be used when the firmware in ota partitions are failing

[valeros]

@Jason2866 many thanks, reproduced. But I’m wandering if this is expected behavior. According to the parttool.py sources, the factory partition is checked first and hence has a higher priority. Could you please point me to documentation stating that factory is used as fallback firmware?

[Jason2866]

Explain differently. Since an empty ota_data partition is used

platform-espressif32/builder/frameworks/espidf.py

Line 2159 in 3c07680

if ota_partition_params["size"] and ota_partition_params["offset"]:

in this case never a firmware of the OTA slots would be started. It is valid to have a factory partition and more OTA partitions. Either the current approach is kept and the marker in (ota_data_initial.bin) which OTA slot should be started needs to be set (currently a empty file) or a change like suggested is needed.
The current approach does not make it possible to use an OTA slot.

[valeros]

Just to make it clear. Two binaries are uploaded at the correct locations (0xE000 for the initial OTA image, 0x10000 for the app image), but the bootloader chooses a wrong partition to boot because the ota_0 contains apparently an empty image, right?

Have you tried the same project (with both OTA and factory partitions) with the native IDF developer environment? It seems that IDF tools behave exactly in the same way.

[Jason2866]

No, OTA_0 at 0xe0000 has a valid firmware (the main firmware), at 0x10000 a factory firmware (for recovery when OTA_0 is defect), and ota_data at xe000 is empty.
Doing this setup with nativ IDF the firmware at 0xe0000 does boot, not the factory firmware at 0x10000
So the behaviour from IDF is as expected. "Somewhere" IDF is doing more or different.

Beside of the behaviour of IDF, not having the possibility to decide what partition starts after flash is at least a strange behaviour. I call it bug and fixed this in my fork.

The cleanest fix would be to set ota_data correctly, honestly i was to lazy for that change (btw. real nice how you included the secure boot stuff!).

[valeros]

No, OTA_0 at 0xe0000 has a valid firmware (the main firmware), at 0x10000 a factory firmware (for recovery when OTA_0 is defect), and ota_data at xe000 is empty.

It seems I missing something. I tried your partition with a project in the native IDF environment. Here is the upload command:

python -m esptool --chip esp32 -b 460800 --before default_reset --after hard_reset -p COM13 write_flash --flash_mode dio --flash_size 4MB --flash_freq 40m 0x1000 build\bootloader\bootloader.bin 0x8000 build\partition_table\partition-table.bin 0xe000 build\ota_data_initial.bin 0x10000 build\hello_world.bin

It uploads the empty OTA image ota_data_initial.bin at 0xe000 and the main application hello_world.bin at 0x10000. I double checked the ota_data_initial.bin file and PlatformIO generates an identical image.

So the question, how come the bootloader boots from 0xe0000 in your case if there is a newly generated empty OTA image at that address? Are there any additional settings in your sdkconfig that I'm missing?