Skip to content

Support arbitrary storage alongside WiFi firmware in external storage on Cypress targets #13436

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

matthew-macovsky-cypress

NOTE: DO NOT MERGE YET

Summary of changes

This change allows for the remainder of external storage to be used for other purposes when the Cypress WiFi firmware is stored in part of it.

Previously on Cypress targets, when the WiFi firmware was stored in external storage, XIP mode would be used to access the firmware. This mode is exclusive with the MMIO mode, preventing the use of QSPI and therefore also preventing the use of a KVStore or a file system in external storage. This change allows the firmware to be read using QSPI and thus allows those storage mechanisms to work alongside it.

Impact of changes

The target CY8CPROTO_062S3_4343W will now use this mechanism by default rather than using XIP.

Documentation

None


Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[X] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[X] Tests / results supplied as part of this PR

GT_FT_KIT_062_BLE_GCC.txt
GT_FT_KIT_062_WIFI_BT_GCC.txt
GT_FT_P6S1_43012EVB_01_GCC.txt
GT_FT_P6S1_43438EVB_01_GCC.txt
GT_FT_PROTO_062S3_4343W.txt
GT_FT_PROTO_062_4343W_GCC.txt
GT_FT_KIT_062S2_43012_GCC.txt

The failures seen are known pre-existing issues.


Reviewers

@ARMmbed/team-cypress


Matthew Macovsky added 6 commits August 13, 2020 11:15
In some toolchains, in order to use linker symbols referring to the
start and end of a region, the region name must not contain a '.'
character. These changes allow those symbols to be used for the cy_xip
region by renaming it. They also create explicit start and end symbols
for GCC.
…d using linker symbols

If the macro CY_STORAGE_WIFI_DATA_OUTPUT is defined, its value is used
as the name of the WiFi firmware storage region to determine the start
and end of.
…assed in

This allows the use of a different resource, buffer, or network
interface from the default when performing WiFi initialization.
Given an underlying block device and the size of the reserved region, a
CyReservedRegionBlockDevice will act as the underlying block device but
operating only outside of the reserved region. It also allows reading
from the reserved region. The reserved region is assumed to start at
address 0 in the underlying block device.
…Cypress WiFi firmware in external memory

This change allows external memory to be used for other purposes while
the WiFi firmware is stored in it by interacting with it via the
reserved region block device.
…Fi firmware

Targets that inherit from this target will have the defines necessary to
place the WiFi firmware in external storage and enable use of the
external WiFi firmware reserved region block device.
Currently, the only target inheriting from this new target is
CY8CPROTO-062S3-4343W.
@ciarmcom
Copy link
Member

@matthew-macovsky-cypress, thank you for your changes.
@maclobdell @ARMmbed/mbed-os-maintainers please review.

@0xc0170
Copy link
Contributor

0xc0170 commented Aug 15, 2020

NOTE: DO NOT MERGE YET

you can use WIP: in the title. I'll mark it as such now.

@0Grit
Copy link

0Grit commented Aug 24, 2020

This still WIP?

@matthew-macovsky-cypress
Copy link
Author

The current plan is for this to remain WIP until upcoming Cypress asset releases. Once those releases are merged, the changes to those assets will be removed from this PR and it will be unmarked as WIP.

@mergify
Copy link

mergify bot commented Sep 9, 2020

This PR cannot be merged due to conflicts. Please rebase to resolve them.

@0xc0170
Copy link
Contributor

0xc0170 commented Sep 10, 2020

If we are going to wait longer, it might be better to close this and reopen once it is ready?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants