In the QSPIFBlockDevice component we checked if BUILD_TESTING was
enabled before adding the QSPIFBlockDevice/UNITTESTS subdirectory. In
the parent blockdevice/CMakeLists.txt we added the QSPIFBlockDevice
subdirectory to the build under two separate conditions:
* when "QSPIF" is present in MBED_TARGET_LABELS
* when building only unit tests
This wasn't quite enough, as when we build greentea tests for some
targets QSPIF is enabled in MBED_TARGET_LABELS, causing the
QSPIFBlockDevice subdirectory and its unit tests to be added when
building greentea tests. This caused a test failure on targets which
enable QSPIF:
```
The following tests FAILED:
40 - qspif-unittest_NOT_BUILT (Not Run)
```
To fix this we need to specifically check that we're not building
greentea tests before adding the QSPIFBlockDevice/UNITTESTS directory to
the project.
Part of this issue is our reliance on MBED_TARGET_LABELS to pull
features in to the build. We should refactor our usage of
MBED_TARGET_LABELS and use CMake target dependencies where possible.
Then we wouldn't need to add subdirectories under various, often
conflicting, scenarios. Instead the targets would always be available
and we would just choose which ones to actually build in different cases
using CMake target linking.
Add a test case to verify that the quirk on `CR1NV` and `CR3NV`
registers get applied by `QSPIFBlockDevice` when the flash device
is S25FS512S.
`QSPIFBlockDevice` depends on the SFDP functions and the `QSPI` class,
but we can't use gMock on them because:
* SFDP functions are global functions, whereas gMock only supports
mocking class member functions.
* A mocked class is injected into the test subject, but passing a
preexisting `QSPI` instance into `QSPIFBlockDevice` is not possible
(unless we resort to pointers). For details, see comments in
test_QSPIFBlockDevice.cpp.
So fakes of the `QSPI` class and any SFDP functions involved are
defined in test_QSPIFBlockDevice.cpp.
The entire flash chip S25FS512S consists of uniform 256KB sectors.
Additionally, it has three configurations:
* 0x01: Eight 4KB sectors (32KB in total) overlaying the start of
the first 256KB sector
* 0x03: Eight 4KB sectors (32KB in total) overlaying the end of the
last 256KB sector
* 0x05: No overlaying sectors
The active configuration is determined from bit fields of two
registers, CR1NV and CR3NV.
Mbed OS does not currently support partially overlaying sectors,
meaning that with eight 4KB sectors overlay a 256KB sectors, the
remaining 224KB (== 256KB - 8 * 4KB) of the big sector can't be
correctly handled. Supporting such scenario would involve a large
amount of rewriting in Mbed OS's BlockDevice, SFDP and their tests,
and may increase the code size.
So, this commit applies a quirk to always report configuration 0x05
(no overlaying sectors). Even if 0x01 or 0x03 is the real configuration,
they are compatible with the 0x05 configuration because 256KB sectors
exist in all cases.
Note: This quirk does *not* change actual configurations on hardware,
because registers CR1NV and CR3NV are one-time configurable (OTP) -
each bit field has a factory value of 0 and can be changed to 1 by the
user but not back to 0. So QSPIFBlockDevice avoids changing them.
Cypress S25FS512S's SFDP table suggests that bit-1 of the register
CR3NV on 25FS512S should equal 1. But it is a known issue that the
value is actually 0 on hardware. So if we query the value of CR3NV
during configuration detection, we can't find a configuration that
matches the SFDP data. This issue has been discussed in the Linux MTD
(Memory Technology Devices) mailing list:
https://linux-mtd.infradead.narkive.com/ylHK6CyT/spi-nor-fs512s-incorrect-cr3nv-1-value
This commit adds a quirk to report bit-1 of CR3NV as 1.
Note: In Mbed OS, vendor-specific quirks can only be handled in block
devices. The SFDP functions assume data from hardware to be correct.
So this quirk is in the block device.
In Mbed OS, each library has an `include/<library>/` subdirectory
containing headers. The recommended way to include a header is
`#include "<library>/<header>.h"` to avoid potential conflicts with
any external modules that have same names of headers.
This is not enforced yet, and both include/ and include/<component>/
are in a library's include paths, to avoid breaking preexisting
Mbed projects that don't follow the recommendation. But code within
Mbed OS should follow it at least.
The SFDP functions parse SFDP data which is fetched by a callback
called `sfdp_reader` provided by {SPIF,QSPIF,OSPIF}BlockDevice.
Currently, this callback interface only takes a read address and an RX
buffer to store output data. This has been enough, because other SPI
parameters are always the same when fetching the SFDP table only -
they are just hardcoded in each reader.
But in the future we will add support for flash devices with multiple
configurations (in a subsequent commit), and to detect which
configuration is enabled, we will need to send detection commands
which require device-dependent SPI parameters:
* address size
* instruction
* dummy cycles
This commit
* turns the above SPI parameters from predefined/hardcoded values
into parameters of the callback
* lets the SFDP functions pass the above parameters to the callback
(Note: To read the SFDP table itself, those values are constants
defined by the standard, not tied to any particular device, so they
can be known to the SFDP functions)
* updates the callbacks implemented by {SPIF,QSPIF,OSPIF}BlockDevice
* updates the mock callback for unit tests and expectations
Add const to function declaration. Const objects cannot access const
safe functions, a compiler error is thrown if one tries to do so. This
helps ensure that the object calling the method will not be modified.
This is espescially desirable in functions where all we need to do is
query existing data and not make any alterations.
[Q/O/SPIFBlockDevice::erase() begin with an alignment check,
after which unaligned erases should not happen or be allowed.
If the erase address is not aligned to the value returned by
sfdp_iterate_next_largest_erase_type(), it indicates an
internal error in erase table parsing which should not be
hidden.
Prior to this PR, the minimum program size (QSPI_MIN_PROG_SIZE) of
QSPIFBlockDevice was 256 by default and 512 for some targets.
Those values were in fact page sizes, not program sizes.
Here's an explanation:
* Most QSPI flashes can be programmed to a granularity of a
single byte or a few bytes - no need to be a whole page.
This should be the value of QSPI_MIN_PROG_SIZE. Applications
need to align buffer sizes to this granularity when
programming QSPI flashes.
* Each sending of the underlying QSPI program signal requires
destination bytes to be located within the same page.
If a QSPIFBlockDevice::program() call crosses page boundaries,
this function breaks down the operation into multiple chunks,
so it's not a concern for the application.
So this PR changes the default program size to 1 (byte), and
for targets with a 4-byte (1-word) read size it overrides the
program size.
Note: No config is needed for the page size, as it comes from
the SFDP table parsed during initialisation.
Aside from the core mbed-os CMake target, a number of targets have been created so they can optionally be included by application executables that require them using `target_link_libraries()`.
Co-authored-by: Martin Kojtal <martin.kojtal@arm.com>
Co-authored-by: Rajkumar Kanagaraj <rajkumar.kanagaraj@arm.com>
The first revision (1.0) of SFDP (ref: JESD216) does not include
fields for software reset support. It's only been added in the
second revision (1.5) (ref: JESD216A).
Some Mbed OS targets such as DISCO_F746NG include flashes with
legacy SFDP, thus we add an option to preset the reset mode.
danielzhang
Uruloke
Robert Walton
Lingkai Dong
Martino Facchin
Martin Kojtal
Harrison Mutai
Hugues Kamba
Hugues Kamba
Rajkumar Kanagaraj