Fix s2 and s3 Cache_Count_Flash_Pages rom function wrapper (IDFGH-14492)

[EliteTK]

Description

The Cache_Count_Flash_Pages rom function on the s2 and s3 only counts one page for any pages which are mapped to page 0 of flash as the Cache_Flash_To_SPIRAM_Copy function attempts to map all flash page 0 mapped pages to one PSRAM page.

As this function can be called for multiple regions, it needs to track if a page mapped to page 0 has previously been accounted for by a previous call. It does this using the page0_mapped in-out parameter. This logic contains an error[0]:

// This code was reverse engineered from the ROM with the help of Ghidra and
// then cleaned up
uint32_t Cache_Count_Flash_Pages(uint32_t bus, uint32_t *page0_mapped)
{
    volatile uint32_t *mmu_table = (volatile uint32_t *)DR_REG_MMU_TABLE;
    uint32_t start, end;
    if (bus == CACHE_IBUS) {
        start = CACHE_IROM_MMU_START;
        end = CACHE_IROM_MMU_END;
    } else {
        start = CACHE_DROM_MMU_START;
        end = CACHE_DROM_MMU_END;
    }

    uint32_t count, page0_count = 0, valid_flash_count = 0;
    for (uint32_t i = start >> 2; i < end >> 2; i++) {
        uint32_t mapping = mmu_table[i];
        if ((mapping & (SOC_MMU_INVALID | SOC_MMU_TYPE)) == (SOC_MMU_VALID | SOC_MMU_ACCESS_FLASH)) {
            if ((mapping & SOC_MMU_VALID_VAL_MASK) == 0) page0_count++;
            valid_flash_count++;
        }
    }
    // BUG: If page0_count is 0, 1 is still added
    // Should be `if (page0_count != 0 && *page0_mapped == 0) {`
    if (*page0_mapped == 0) {
        count = valid_flash_count + 1 - page0_count;
    } else {
        count = valid_flash_count - page0_count;
    }
    *page0_mapped += page0_count;
    return count;
}

The current Cache_Count_Flash_Pages wrapper in the idf attempts to compensate for this bug by checking if the page0_mapped parameter was changed by a call to the function and reducing the count if it has not.

This, however, will incorrectly over-compensate in situations where the initial value of page0_mapped was not zero as the code above only miscounts when it was zero.

This patch addresses the issue in this wrapper function by correctly compensating for the bug only in cases where the final page0_mapped value is 0.

Testing

I used a ESP32-S3 based LCD board to run code which made use of CONFIG_SPIRAM_FETCH_INSTRUCTIONS and CONFIG_SPIRAM_RODATA, I added some additional verbose logging in mmu_config_psram_text_segment and mmu_config_psram_rodata_segment to check the calculated page count and compare it to the change in page_id after the SPIRAM copy is performed.

Since my code did not result in page0 getting mapped (I'm not sure how to arrange for that organically), I manually triggered the issue by initialising page0_mapped to 1 which resulted in the original code under-counting the total number of required pages by 1 in each instance of the function being called.

With the fix applied, the count matched the jump in page number that subsequent calls to Cache_Flash_To_SPIRAM_Copy resulted in. This was tested both in cases which did and cases which did not trigger the bug.

Checklist

Before submitting a Pull Request, please ensure the following:

• 🚨 This PR does not introduce breaking changes.
  NOTE: This change would only break code which would already break due to a lack of PSRAM space.
• All CI checks (GH Actions) pass.
• Documentation is updated as needed.
• Tests are updated or added as necessary.
• Code is well-commented, especially in complex areas.
• Git history is clean — commits are squashed to the minimum necessary.

[CLAassistant]

All committers have signed the CLA.

[github-actions]

	Warnings
⚠️	Some issues found for the commit messages in this PR: the commit message "Fix s2 and s3 Cache_Count_Flash_Pages rom function wrapper": summary looks empty type/action looks empty Please fix these commit messages - here are some basic tips: follow Conventional Commits style correct format of commit message should be: <type/action>(<scope/component>): <summary>, for example fix(esp32): Fixed startup timeout issue allowed types are: change,ci,docs,feat,fix,refactor,remove,revert,test sufficiently descriptive message summary should be between 20 to 72 characters and start with upper case letter avoid Jira references in commit messages (unavailable/irrelevant for our customers) TIP: Install pre-commit hooks and run this check when committing (uses the Conventional Precommit Linter).
⚠️	The source branch "Cache_Count_Flash_Pages-patch-fix" incorrect format: contains uppercase letters. This can cause troubles on case-insensitive file systems (macOS). Please rename your branch.

👋 Hello EliteTK, we appreciate your contribution to this project!

---

📘 Please review the project's Contributions Guide for key guidelines on code, documentation, testing, and more.

---

🖊️ Please also make sure you have read and signed the Contributor License Agreement for this project.

---

Click to see more instructions ...

This automated output is generated by the PR linter DangerJS, which checks if your Pull Request meets the project's requirements and helps you fix potential issues.

DangerJS is triggered with each push event to a Pull Request and modify the contents of this comment.

Please consider the following:
- Danger mainly focuses on the PR structure and formatting and can't understand the meaning behind your code or changes.
- Danger is not a substitute for human code reviews; it's still important to request a code review from your colleagues.
- Resolve all warnings (⚠️ ) before requesting a review from human reviewers - they will appreciate it.
- To manually retry these Danger checks, please navigate to the Actions tab and re-run last Danger workflow.

Review and merge process you can expect ...

We do welcome contributions in the form of bug reports, feature requests and pull requests via this public GitHub repository.

This GitHub project is public mirror of our internal git repository

1. An internal issue has been created for the PR, we assign it to the relevant engineer.
2. They review the PR and either approve it or ask you for changes or clarifications.
3. Once the GitHub PR is approved, we synchronize it into our internal git repository.
4. In the internal git repository we do the final review, collect approvals from core owners and make sure all the automated tests are passing.
- At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
5. If the change is approved and passes the tests it is merged into the default branch.
5. On next sync from the internal git repository merged change will appear in this public GitHub repository.

Generated by 🚫 dangerJS against f2ec2c8