Skip to content
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

Enable the RWW function of Macronix Flash MX25LW51245G in OSPI block device driver #14221

Merged
merged 5 commits into from
Jun 2, 2021

Conversation

rogeryou
Copy link
Contributor

@rogeryou rogeryou commented Feb 1, 2021

Summary of changes

Update PR #12644.

Add source code about RWW(read while write) in OSPI block device driver for using the RWW function Macronix octaflash MX25LW51245G to improve performance.

Impact of changes

Enable the RWW function of MX25LW51245G.

Migration actions required

Documentation

N/A

N/A

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

This driver is tested on DISCO_L4R9I. The flash on this board is MX25LM51245G. You need to replace it with MX25LW51245G.
The test case for RWW is "Testing read while write and read while erase". You also need to replace MX25LM51245G with MX25LW51245G about DISCO_L4R9I in target.json.

target platform_name test suite test case passed failed result elapsed_time (sec)
DISCO_L4R9I-GCC_ARM DISCO_L4R9I storage-blockdevice-tests-tests-blockdevice-general_block_device DEFAULT Testing get type functionality 1 0 OK 0.11
DISCO_L4R9I-GCC_ARM DISCO_L4R9I storage-blockdevice-tests-tests-blockdevice-general_block_device OSPIF Testing BlockDevice erase functionality 1 0 OK 0.41
DISCO_L4R9I-GCC_ARM DISCO_L4R9I storage-blockdevice-tests-tests-blockdevice-general_block_device OSPIF Testing Deinit block device 1 0 OK 0.09
DISCO_L4R9I-GCC_ARM DISCO_L4R9I storage-blockdevice-tests-tests-blockdevice-general_block_device OSPIF Testing Init block device 1 0 OK 0.09
DISCO_L4R9I-GCC_ARM DISCO_L4R9I storage-blockdevice-tests-tests-blockdevice-general_block_device OSPIF Testing contiguous erase, write and read 1 0 OK 0.62
DISCO_L4R9I-GCC_ARM DISCO_L4R9I storage-blockdevice-tests-tests-blockdevice-general_block_device OSPIF Testing multi threads erase program read 1 0 OK 3.45
DISCO_L4R9I-GCC_ARM DISCO_L4R9I storage-blockdevice-tests-tests-blockdevice-general_block_device OSPIF Testing program read small data sizes 1 0 OK 0.33
DISCO_L4R9I-GCC_ARM DISCO_L4R9I storage-blockdevice-tests-tests-blockdevice-general_block_device OSPIF Testing read while write and read while erase 1 0 OK 0.55
DISCO_L4R9I-GCC_ARM DISCO_L4R9I storage-blockdevice-tests-tests-blockdevice-general_block_device OSPIF Testing read write random blocks 1 0 OK 0.89
DISCO_L4R9I-GCC_ARM DISCO_L4R9I storage-blockdevice-tests-tests-blockdevice-general_block_device OSPIF Testing unaligned erase blocks 1 0 OK 0.11
DISCO_L4R9I-GCC_ARM DISCO_L4R9I storage-blockdevice-tests-tests-blockdevice-general_block_device OSPIF Testing write -> deinit -> init -> read 1 0 OK 0.18

Reviewers

@jeromecoutant Please review.


@ciarmcom
Copy link
Member

ciarmcom commented Feb 1, 2021

@rogeryou, thank you for your changes.
@jeromecoutant @ARMmbed/mbed-os-core @ARMmbed/team-st-mcd @ARMmbed/mbed-os-maintainers please review.

@ciarmcom
Copy link
Member

ciarmcom commented Feb 1, 2021

@rogeryou, thank you for your changes.
@ARMmbed/team-st-mcd @ARMmbed/mbed-os-maintainers please review.

@rogeryou rogeryou marked this pull request as ready for review February 2, 2021 02:01
@0xc0170
Copy link
Contributor

0xc0170 commented Feb 2, 2021

Please fix the styling

#define MX25LM51245G_CHUNK_SIZE 0x10 /* fred: 16 bytes */

#ifdef MX_FLASH_SUPPORT_RWW
#define MX25LM51245G_BANK_SIZE 0x01000000 /* fred: 16 MBytes */
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why you don't create a new file MX25LW51245G_config.h ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have created a new file MX25LW51245G_config.h .

@@ -62,6 +62,8 @@
#define MBED_CONF_OSPIF_OSPI_FREQ 40000000
#endif

#define MX_FLASH_SUPPORT_RWW
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not related to the memory ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is.
I have moved it to MX25LW51245G_config.h.

Copy link
Collaborator

@jeromecoutant jeromecoutant left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DISCO_L4R9I doesn't compile any more :-(

OSPIF_CR2_OPI_EN_ADDR is missing

@rogeryou
Copy link
Contributor Author

rogeryou commented Feb 4, 2021

DISCO_L4R9I doesn't compile any more :-(

OSPIF_CR2_OPI_EN_ADDR is missing

I have fixed this issue.

Copy link
Collaborator

@jeromecoutant jeromecoutant left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non regression tests OK

@@ -34,7 +34,7 @@

/* Max amount of flash size is 4Gbytes */
/* hence 2^(31+1), then FLASH_SIZE_DEFAULT = 1<<31 */
#define OSPI_FLASH_SIZE_DEFAULT 0x80000000
#define OSPI_FLASH_SIZE_DEFAULT 0x4000000 //512Mbits
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't understand why driver is using a "default" flash size...?
All octo SPI are the same?
(maybe comment above is wrong now?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is copy from qspi_api.c.
I found a issue about this value.
I modified the code below.
obj->handle.Init.DeviceSize = POSITION_VAL(OSPI_FLASH_SIZE_DEFAULT) - 1;

obj->handle.Init.DeviceSize = 32;

The driver need to execute command RDCR2 to read the bank status of flash. This command need to send address(0xC0000000> OSPI_FLASH_SIZE_DEFAULT). The controller will report error when i execute RDCR2.
SO i need to change the value of DeviceSize.

Comment on lines +30 to +35
#define MX_FLASH_BLOCK_SIZE 0x10000 /* 1024 blocks of 64 KBytes */
#define MX_FLASH_SECTOR_SIZE 0x1000 /* 16384 sectors of 4 kBytes */
#define MX_FLASH_PAGE_SIZE 0x100 /* 262144 pages of 256 bytes */
#define MX_FLASH_CHUNK_SIZE 0x10 /* 16 bytes */
#define MX_FLASH_BANK_SIZE 0x01000000 /* 16 MBytes */
#define MX_FLASH_BANK_SIZE_MASK ~(MX_FLASH_BANK_SIZE - 1) /* 0xFF000000 */
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Macro not used ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes , these Macro are not used in this version. They will be used in VEEBlockDevice driver which I will push to github later.

Comment on lines -29 to -36
#ifdef NEED_DEFINE_SFDP_PARA
uint8_t _sfdp_head_table[32] = {0x53, 0x46, 0x44, 0x50, 0x06, 0x01, 0x02, 0xFF, 0x00, 0x06, 0x01,
0x10, 0x30, 0x00, 0x00, 0xFF, 0xC2, 0x00, 0x01, 0x04, 0x10, 0x01,
0x00, 0xFF, 0x84, 0x00, 0x01, 0x02, 0xC0, 0x00, 0x00, 0xFF
};
uint8_t _sfdp_basic_param_table[64] = {0x30, 0xFF, 0xFB, 0xFF, 0xFF, 0xFF, 0xFF, 0x1F, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x01, 0x14, 0xEC,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x0C, 0x20,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would think that values for this workaround is specific for each OSPI,
so this should be kept in this config file ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with you. But it will report some errors when compiled if more than one file include this config file. _sfdp_head_table will be redefined.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as these should be rather const and static if in header file to avoid that.
Moving to code file if they are not reused anywhere is fine.

@ciarmcom ciarmcom added the stale Stale Pull Request label Feb 8, 2021
@ciarmcom
Copy link
Member

ciarmcom commented Feb 8, 2021

This pull request has automatically been marked as stale because it has had no recent activity. @ARMmbed/mbed-os-maintainers, @ARMmbed/mbed-os-core, please complete review of the changes to move the PR forward. Thank you for your contributions.

0xc0170
0xc0170 previously approved these changes Feb 8, 2021
Comment on lines -29 to -36
#ifdef NEED_DEFINE_SFDP_PARA
uint8_t _sfdp_head_table[32] = {0x53, 0x46, 0x44, 0x50, 0x06, 0x01, 0x02, 0xFF, 0x00, 0x06, 0x01,
0x10, 0x30, 0x00, 0x00, 0xFF, 0xC2, 0x00, 0x01, 0x04, 0x10, 0x01,
0x00, 0xFF, 0x84, 0x00, 0x01, 0x02, 0xC0, 0x00, 0x00, 0xFF
};
uint8_t _sfdp_basic_param_table[64] = {0x30, 0xFF, 0xFB, 0xFF, 0xFF, 0xFF, 0xFF, 0x1F, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x01, 0x14, 0xEC,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x0C, 0x20,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as these should be rather const and static if in header file to avoid that.
Moving to code file if they are not reused anywhere is fine.

@mergify mergify bot added the needs: CI label Feb 8, 2021
@0xc0170
Copy link
Contributor

0xc0170 commented May 7, 2021

CI restarted

@mbed-ci
Copy link

mbed-ci commented May 7, 2021

Jenkins CI Test : ❌ FAILED

Build Number: 5 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs Status
jenkins-ci/mbed-os-ci_unittests ✔️
jenkins-ci/mbed-os-ci_cmake-cloud-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-cloud-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-cloud-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_cmake-cloud-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_cmake-example-ARM ✔️
jenkins-ci/mbed-os-ci_cmake-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-example-ARM

@0xc0170
Copy link
Contributor

0xc0170 commented May 10, 2021

CI restarted

@mbed-ci
Copy link

mbed-ci commented May 10, 2021

Jenkins CI Test : ❌ FAILED

Build Number: 6 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs Status
jenkins-ci/mbed-os-ci_unittests ✔️
jenkins-ci/mbed-os-ci_build-cloud-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-cloud-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_cmake-cloud-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_cmake-cloud-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-ARM ✔️
jenkins-ci/mbed-os-ci_cmake-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_cmake-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_greentea-test

@mergify mergify bot added needs: work and removed needs: CI labels May 10, 2021
@0xc0170
Copy link
Contributor

0xc0170 commented May 10, 2021

One more restart

@mbed-ci
Copy link

mbed-ci commented May 10, 2021

Jenkins CI Test : ❌ FAILED

Build Number: 7 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs Status
jenkins-ci/mbed-os-ci_build-cloud-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_cmake-cloud-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_cmake-cloud-example-ARM ✔️
jenkins-ci/mbed-os-ci_unittests ✔️
jenkins-ci/mbed-os-ci_build-cloud-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_cmake-example-ARM ✔️
jenkins-ci/mbed-os-ci_cmake-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_greentea-test

@mergify mergify bot added needs: work and removed needs: CI labels May 10, 2021
@ciarmcom ciarmcom added stale Stale Pull Request and removed stale Stale Pull Request labels May 20, 2021
@ciarmcom ciarmcom added stale Stale Pull Request and removed stale Stale Pull Request labels May 28, 2021
@0xc0170 0xc0170 added needs: CI and removed needs: work stale Stale Pull Request labels Jun 2, 2021
@mbed-ci
Copy link

mbed-ci commented Jun 2, 2021

Jenkins CI Test : ✔️ SUCCESS

Build Number: 8 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs Status
jenkins-ci/mbed-os-ci_unittests ✔️
jenkins-ci/mbed-os-ci_build-cloud-example-ARM ✔️
jenkins-ci/mbed-os-ci_cmake-cloud-example-ARM ✔️
jenkins-ci/mbed-os-ci_cmake-cloud-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-cloud-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-ARM ✔️
jenkins-ci/mbed-os-ci_cmake-example-ARM ✔️
jenkins-ci/mbed-os-ci_cmake-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_greentea-test ✔️

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

Successfully merging this pull request may close these issues.

7 participants