-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Improve QSPIFBlockDevice conformance to SFDP #11531
Conversation
This is a WIP submission to gather feedback while we finalize our internal review and testing. |
@kyle-cypress, thank you for your changes. |
@@ -380,7 +380,7 @@ int QSPIFBlockDevice::erase(bd_addr_t addr, bd_size_t in_size) | |||
int type = 0; | |||
uint32_t offset = 0; | |||
uint32_t chunk = 4096; | |||
unsigned int cur_erase_inst = _erase_instruction; | |||
qspi_inst_t cur_erase_inst = _erase_instruction; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the reason for this change? I dont see anything in the commit msg to explain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consistency - the current code uses a mixture of signed and unsigned integers to represent instruction values
Clarity - convey the meaning better of the data than a generic int
(and encourage consistency)
Efficiency: The instruction is only 8 bits wide, so size the data type to fit.
@ARMmbed/mbed-os-storage Can you please review this proposal? |
drivers/QSPI.h
Outdated
@@ -160,7 +166,7 @@ class QSPI : private NonCopyable<QSPI> { | |||
* @returns | |||
* Returns QSPI_STATUS_SUCCESS on successful reads and QSPI_STATUS_ERROR on failed reads. | |||
*/ | |||
qspi_status_t read(int instruction, int alt, int address, char *rx_buffer, size_t *rx_length); | |||
qspi_status_t read(qspi_inst_t instruction, int alt, int address, char *rx_buffer, size_t *rx_length); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
int
should be sufficient for inst as it can be any number, narrow down this won't make much difference here.
Same as alt, address and others.
This is breaking change, so needs to be justified to go in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The usage of this in the block device was wrong, should follow what the driver specifies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The usage of this in the block device was wrong, should follow what the driver specifies.
Can you clarify what you mean? Are you saying that the use of unsigned int
instead of int
in the block device was wrong?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
int
should be sufficient for inst as it can be any number, narrow down this won't make much difference here.Same as alt, address and others.
This is breaking change, so needs to be justified to go in.
This change is not mandatory for the fix here so I can pull it out of this review and into a separate PR if it makes things easier. But in principle, shouldn't values which correspond to bit patterns of a particular width be represented as types of particular widths? If so, then I would argue that a separate PR should also replace alt
and address
with more specific types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not that familiar with SQPIF, but if commands are limited to 8 bytes, then I would say that this is acceptable, and it is not a breaking change.
Mbed OS have not guaranteed to have binary compatibility, so moving from int to uint8_t should be OK.
This again changes a driver and the block device - as these are two different areas, it would be good to split them, driver first - if accepted, block device can be updated. Otherwise this takes a longer time to review and integrate (they are dependent on each other). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are lots of changes not related to QSPIF, can you split your changes to separate PRs so that we can properly review each change on its own.
Currently I'm not able to understand why this PR touches things like LittleFS, KVStore and DeviceKey.
Yes, I will split out the related refactoring and cleanups into their own PRs that this one can then depend on. |
Separated out #11604 for the qspi_inst_t change (will rebase this PR to remove that commit soon) |
29f9288
to
e21345d
Compare
I've made the following updates:
|
|
||
_mutex.lock(); | ||
|
||
// All commands other than Read and RSFDP use default 1-1-1 bus mode (Program/Erase are constrained by flash memory performance more than bus performance) | ||
_qspi.configure_format(QSPI_CFG_BUS_SINGLE, QSPI_CFG_BUS_SINGLE, _address_size, QSPI_CFG_BUS_SINGLE, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you need to check return value from configure_format()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the return value needs to be checked for configure_format across the board, but that is handled in #11603 (applying the check to additional/relocated configure_format calls would be handled during the rebase of whichever PR goes in second).
@ARMmbed/mbed-os-maintainers - Can this be merged. It seems the issues have been addressed. Please confirm. |
CI started |
Use a vendor id check to only perform this enable on devices which define the second configuration register where the fast mode enable bit lives. Change _enable_fast_mode to use the standard status register reading and writing functions
4-byte addressing has been seen to cause failures on NORDIC boards and with Macronix memories. Suppress the attempt to enable it on that hardware (via vendor quirks and a target check) until either the failure cause can be fixed or a more robust suppression mechanism is implemented.
The addition of trace logging during greentea tests pushes the multithreaded read-write test beyond the limits of the stack it allocates for its threads. The increase of 128 bytes was chosen by experimentation.
073285a
to
0103e3a
Compare
1.) Rebased on latest master in hopes that, if I understood the comment correctly, this will pull in a fix for the issue @jeromecoutant was encountering. This will probably still fail on NRF52840_DK with a timeout. This is because the extensive debug-level tracing in QSPIFBlockDevice, which is now enabled during the CI, causes the general block device test to slow down substantially while it waits for the UART (in my testing it increased from ~2 minutes to 10-15). The kvstore static test looks like it has a similar issue. @maclobdell plans to seek agreement on the proper way to resolve this early tomorrow morning. |
@0xc0170 Really? trace should not be enabled by default.... |
@jeromecoutant This was to help debugging the previous issues, before we start a new CI, will disable that. |
CI restarted (tracing disabled) |
Test run: FAILEDSummary: 1 of 11 test jobs failed Failed test jobs:
|
@kyle-cypress One failure for k64f in the logs, please review
Looks like deinit test case failing only, @ARMmbed/mbed-os-storage would you be able to reproduce this one for k64f? |
@kyle-cypress Looks like the failure is K64F on gcc_arm:
|
after talking to the maintainers, I think the K64F test fail could be real. I will test it manually. Since the kvstore tests were touched and this PR is the only one that K64F kvstore tests are failing, it needs t obe investigated. Perhaps another increase of stack size is necessary. Will try to resolve by the end of today. Any help and support anyone can provide is much appreciated. |
Thanks @maclobdell . Please let me know if you need any help debugging. For reference, the commit that changed that test is 92829bd (a1c7403 also touches that file, but just to add PSOC6 to the set of targets on which it runs). |
The kvstore failure on K64F definitely seems to be intermittent though. In the second run of the results referenced by #11531 (comment), the kvstore tests pass on K64F and the only failure was networking related. |
@0xc0170 CI now seems to have passed on this ? |
yes, restarted as above made a point about the last run (this confirms it, 2x subsequent run are all OK). Lets get this in and check nightly in the morning |
I have been running kvstore tests on 3 different FRDM-K64F on the master branch, before and after this PR was merged. I see different intermittent failures across different boards, but I see the same failures before and after this PR. mostly I see these tests failing, but it doesn't seem to be related at all to this PR, unless the flash is getting left in a weird state and causing the test to fail subsequent runs. features-storage-tests-kvstore-filesystemstore_tests | Testing Edge Cases |
Thanks @maclobdell for the report. I've just noticed failures in some other PRs and nightly as well, going to create a new issue to track this. |
mbed-os PR 11531 introduced 4-byte addressing in the QSPIF block device: ARMmbed#11531 During testing it was found that this code broke on the NRF52840_DK and DISCO_F769NI. The NRF52840_DK controller seems unable to handle 4-byte addressing at all and has been disabled entirely in another code section. The DISCO_F769NI breakage was attributed to the flash chip but after more research I believe this is related to the QSPI controller, not the 4-byte addressing itself. Now that the QSPI controller has a workaround, enable 4-byte addressing again and hope it works fine this time.
mbed-os PR 11531 introduced 4-byte addressing in the QSPIF block device: ARMmbed#11531 During testing it was found that this code broke on the NRF52840_DK and DISCO_F769NI. The NRF52840_DK controller seems unable to handle 4-byte addressing at all and has been disabled entirely in another code section. The DISCO_F769NI breakage was attributed to the flash chip but after more research I believe this is related to the QSPI controller, not the 4-byte addressing itself. Now that the QSPI controller has a workaround, enable 4-byte addressing again and hope it works fine this time.
* STM32F7: Unconditionally enable QSPI workarounds On the STM32769NI at least this patch is required for stable QSPI use. Enable it uncondtionally in case other boards need it too. Further discussions: ARMmbed#10049 ARMmbed#15108 STMicroelectronics/STM32CubeF7#52 STMicroelectronics/STM32CubeF7#82 * QSPIF: Attempt 4-byte addressing on Macronix chips mbed-os PR 11531 introduced 4-byte addressing in the QSPIF block device: ARMmbed#11531 During testing it was found that this code broke on the NRF52840_DK and DISCO_F769NI. The NRF52840_DK controller seems unable to handle 4-byte addressing at all and has been disabled entirely in another code section. The DISCO_F769NI breakage was attributed to the flash chip but after more research I believe this is related to the QSPI controller, not the 4-byte addressing itself. Now that the QSPI controller has a workaround, enable 4-byte addressing again and hope it works fine this time.
mbed-os PR 11531 introduced 4-byte addressing in the QSPIF block device: ARMmbed#11531 During testing it was found that this code broke on the NRF52840_DK and DISCO_F769NI. The NRF52840_DK controller seems unable to handle 4-byte addressing at all and has been disabled entirely in another code section. The DISCO_F769NI breakage was attributed to the flash chip but after more research I believe this is related to the QSPI controller, not the 4-byte addressing itself. Now that the QSPI controller has a workaround, enable 4-byte addressing again and hope it works fine this time.
Description
Proposed fix for #11530 .
In several cases QSPIFBlockDevice does not conform to the SFDP standard JESD216. These include:
In these cases QSPIFBlockDevice often assumes that certain instructions or methods are universal across flash devices when they are not. This can cause issues in devices that do not match these assumptions. This pull request resolves many of these issues and better aligns QSPIFBlockDevice with JESD216.
This PR is dependent on #11604
Pull request type
Reviewers
Release Notes