Add support for supplying power to the flash chip by activation of
a GPIO specified through the "supply-gpios" property. Implementation
of gpio_reset() is also slightly modified so that it is consistent
with soft_reset() and the new power_supply() and so that all these
functions can use a common routine that performs a reset recovery
delay.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Using a GPIO reset for a flash chip that has a dual function pin
(RESET# or SIO3) and is to be used in Quad mode is rather a bad idea
and so is clearing of the Quad Enable bit at every initialization
of the flash driver, since this bit is usually non-volatile, so such
operation means unnecessary wearing of the flash chip. Soft Reset
should be use instead in such case.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Add implementation of the most common Soft Reset routine (sequence of
reset enable instruction 0x66 and reset instruction 0x99).
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Complete implementation of quad_enable_set() by adding support for all
possible Quad Enable Requirements (QER) as specified by the SFDP JEDEC
standard (JESD216). Add also corresponding octal_enable_set() to handle
Octal Enable Requirements.
Also remove initial waiting from mxicy_mx25r_post_switch_mode() which
became unneeded, as now such waiting is done in cmd_wrsr() which is
called at the end of quad_enable_set().
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
- Use standard operation codes and parameters from SFDP for handling
the used flash commands (allow to override some of them through dts
with the `read-command`, `write-command`, and `rx-dummy` properties)
- Use all available erase types as specified by SFDP
- Allow using all IO modes
- Add support for switching to 4-byte addressing mode
- Use common functions for reading and writing of status registers
and for enabling write operations
- Switch IO mode (between the target one and Single IO) in a common
function that performs transfers and do it only when required for
a given command
- Make checking of JEDEC ID at initialization optional
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Get parameters for used flash commands and requirements for enabling
Quad and Octal modes from dts uint8-arrays containing data read from
SFDP tables for particular flash chips.
Also introduce `pre_init` quirk that allows alteration of the above
parameters or complementation of them in a specific way for particular
flash chip families.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Asynchronously release the device after a small delay to minimise power
state transitions under multiple sequential API calls (e.g. NVS).
Signed-off-by: Jordan Yates <jordan@embeint.com>
According to the datasheet, one page is made of 64 bytes
and one row is made of 4 pages, that is 256 bytes.
This MR fixes the incorrect page write size for sam0
and sets it to 64 bytes.
Signed-off-by: Taras Zaporozhets <zaporozhets.taras@gmail.com>
The following error is issued by clang when building with
SPI_NOR_SFDP_RUNTIME enabled:
error: fields must have a constant size:
'variable length array in structure' extension will never be supported
1379 | uint32_t dw[MIN(php->len_dw, 20)];
Instead, hardcode the array length to 20 32-bit words (it's instantiated
in the stack anyway).
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
In HAL based stm32 drivers, dma handling is done internally to HAL.
Though, in order to avoid a dma_config() call is done to ensure stream
will be set as busy in zephyr dma driver to avoid potential resource
sharing conflict.
This dma_config() call was done while taking into account
STM32_DMA_STREAM_OFFSET, which is wrong as it will prevent zephyr dma
driver to set the right stream as busy.
Fix this in impacted drivers.
Signed-off-by: Erwan Gouriou <erwan.gouriou@st.com>
The AT25XV021A variant is a flash variant of Atmel's AT25 family
that adds extra protections, requiring additional writes to the
device to program or erase data.
This commit adds a flash driver for AT25XV021A devices instead of
modifying (1) the existing AT45 SPI flash driver or (2) the
existing AT24/25 EEPROM driver because this variant poses
fundamental changes that affect all aspects of the driver.
Notably,
- AT25XV021A includes a second status register, and the format
and functions of the existing status register is
changed from the existing drivers.
- AT25XV021A requires executing page or chip erase commands
before writing, making it incompatible with the
existing AT24/25 EEPROM driver.
- AT25XV021A adds a software protection layer that requires
extra writes before executing program or erase commands.
Tested writing to and erasing from an AT25XV021A device. Tested
reading from an AT25XV021A device across page boundaries. Tested
chip erase function. Tested driver initialization from varying
initial hardware states.
Signed-off-by: Liam Ogletree <liam.ogletree@cirrus.com>
This commit is fixing configuration of mx66uw1g45g NOR when working
at 200MHz.
According to its specification, when running at 200MHz, this memory should
use a Number Dummy Cycles configuration of 20 (DC bits in CFGR2), which is
the device's default configuration.
Applying the 66MHz configuration as done today was preventing flash to run
at frequency higher than 100Mhz.
This commit doesn't solve the more generic problem of this driver which
is applying this 66MHz configuration universally, irrespective of the
frequency and the memory device, but fixes the configuration which was
reported broken today.
Providing a global change would require starting a clear split between XSPI
controller configuration an bus device configuration, which is what new
MSPI API intend to solve, so this will be tackled once this driver will be
available.
Signed-off-by: Erwan Gouriou <erwan.gouriou@st.com>
When the application is executed in external flash, the read operation
cannot be in indirect mode but with memcopy.
Note that writing or erasing the external flash being executed
is not possible during the execution.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Commit df0f74d491c851b3e7e970f898c5c2fc3aab5b80 added a shell command to be
able to print out the partitions. However the label property is optional.
Print both the name and label if available.
Signed-off-by: Pieter De Gendt <pieter.degendt@basalte.be>
Add a guard clause in flash_esp32_read() to return 0 when the
requested length is zero. This avoids unnecessary operations
and aligns with expected flash API behavior, where reading
zero bytes is treated as a no-op.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Add a workaround for `NRF53_ERRATA_159_ENABLE_WORKAROUND`
instead of simply printing an error and failing the transaction.
Signed-off-by: Anthony Williams <anthony289478@gmail.com>
For devices other than the stm32h745/747/755/757 that use
dual-core cortex-M4/cortex-M7, do not multiply flash
controller size by 2. Single-core stm32h7x devices define
their flash-controllers dtsi as a single area, not two banks.
Use the presence of the bank2-flash-size prop to determine if
this is a dual-core stm3h7x or not.
Signed-off-by: Rory Piper <rory.piper@signal-fire.com>
This commit adds support for the new cs-high-time devicetree property.
The QUADSPI_DCR_CSHT is now configured according to the value indicated
in the devicetree, for both single and dual flash modes.
Signed-off-by: Thomas Altenbach <altenbach.thomas@gmail.com>
The QSPI 1/2 sample shift (SSHIFT) was only enabled in dual flash mode.
This feature is useful to guarantee that data is ready at the sampling
moment, even if the signals are a bit delayed due to PCB constraints.
Therefore, it should be enabled when possible (only supported in STR
mode).
Signed-off-by: Thomas Altenbach <altenbach.thomas@gmail.com>
Remove these legacy kconfig, not necessary.
The DT already has the bindings and nodes required to represent if there
is a FlexSPI and/or SEMC.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
- Adds JEDEC-ID check to the flash_mcux_flexspi driver
if it is defined in DTS.
- Avoids applying DTS settings to a different flash module.
Signed-off-by: Andrej Butok <andrey.butok@nxp.com>
Add the extended operations to the Andes XIP flash driver.
The extended operations supports:
- reading status registers of the flash chip
- changing status registers of the flash chip
- software lock of the status registers
- modifying SPI read command used in memory-mapped mode
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
The flash M1K driver supports read (up to 1K), write (1K), and
erase (4K) operations, which can be accessed via DLM.
Accessible flash regions include internal e-Flash or external SPI
flash via FSCE# or FSCE1#.
Signed-off-by: Tim Lin <tim2.lin@ite.corp-partner.google.com>
- Adds CONFIG_FLASH_PAGE_LAYOUT check to the flash_mcux_flexspi
drivers.
- Saves some memory if FLASH_PAGE_LAYOUT is disabled.
Signed-off-by: Andrej Butok <andrey.butok@nxp.com>
Remove cache invalidation after flash write,
cpu should automatically invalidate cache but
for HW erase invalidation needed due to erase
from different bus.
Signed-off-by: Travis Lam <travis.lam@nordicsemi.no>
Although the value currently hard-coded in the driver (10 ms) is quite
high, it may turn out to be insufficient when there is a need to use
some very low SCK frequency, like 250 kHz.
Make the timeout value configurable per-instance, via devicetree.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Cleaned up the flash_rpi_pico driver to improve code readability and
compliance with Zephyr coding standards. Fixed inconsistent indentation
across the file and removed variables that were declared but not used.
A few improvements are credited to Manu3l0us.
Signed-off-by: Hanan Arshad <hananarshad619@gmail.com>
The Raspberry Pi Pico 2 uses a QMI flash controller, which differs from the
SSI controller used in the original Pico. Zephyr already has support for
the SSI controller, but lacked support for QMI.
This change adds the QMI flash controller implementation in the
flash_rpi_pico.c driver file. Additionally, the RP2350 SoC devicetree file
(rp2350.dtsi) has been updated to enable and describe the flash controller
for Pico 2.
Signed-off-by: Hanan Arshad <hananarshad619@gmail.com>
Use wrapper function for read operations to allow using the new HAL
function that handles ECC checks and erased page detection.
Signed-off-by: Tahsin Mutlugun <Tahsin.Mutlugun@analog.com>
To fix MAX32690 flash problems, I created a wrap version of
MXC_FLC_Write(...) function which disables ICC before calling write
function and enables ICC after this function.
Signed-off-by: Furkan Akkiz <hasanfurkan.akkiz@analog.com>
Disable interrupts during flash operations to prevent unintended jumps.
Interrupts are now disabled before read, erase, and write operations to
avoid accidental jumps to other flash sections while working on a
specific section.
Signed-off-by: Tahsin Mutlugun <Tahsin.Mutlugun@analog.com>
When dual-flash mode is enabled, any erase operation is executed on both
flash memories in parallel. This means from the flash driver's point of
view, the size of a given sector/block is twice the size of a
sector/block on a single flash memory.
For example, assuming 4-KiB sectors for each flash memory, if the flash
driver is asked to erase at address 0x0000, the erase size must be a
multiple of 8 KiB since each sector erase operation will cause a 4-KiB
sector to erased in each flash memory.
Before this commit, the doubled erase size was only considered in
'setup_pages_layout'. Now, the actual sizes of the erase operations are
properly set in the flash driver's data and are used everywhere in the
driver.
Signed-off-by: Thomas Altenbach <altenbach.thomas@gmail.com>
When dual-flash mode is enabled, even bytes are written to the first
flash memory and odd bytes to the second flash memory. This means, from
the flash driver's point of view, the size of a flash page is twice the
size of a single flash memory's page.
So if each flash memory has 256-byte pages, 512 bytes should be used as
page size by the flash driver. Using 256 bytes was working fine but is
suboptimal.
Signed-off-by: Thomas Altenbach <altenbach.thomas@gmail.com>
When dual-flash mode is enabled, two identical flash memories are
connected to the QUADSPI peripheral, each having its own set of
registers. This means that when reading or writing a flash register,
this has to be made for both flash memories.
For example, when reading a status register (1 byte), the QUADSPI
peripheral must be configured to read two bytes of data, which
correspond respectively to the value of the register in the first and
second flash memory. Same thing when writing.
Before this commit, when dual-flash mode was enabled, only the register
of the first flash memory was considered, which means the second flash
memory could be incorrectly configured and that any write/erase
operation could be considered as completed too early, if the operation
takes more time to complete for the second flash memory.
Signed-off-by: Thomas Altenbach <altenbach.thomas@gmail.com>
The 'qspi_read_status_register' routine implements the reading of a
flash memory's status register. This routine is used anytime reading a
status register is needed, except in 'qspi_wait_until_ready'. This
commit moves the read routine to be able to use it in
'qspi_wait_until_ready'. The 'qspi_write_status_register' is also moved
to keep it close to the read routine.
Signed-off-by: Thomas Altenbach <altenbach.thomas@gmail.com>
In multiple places, "#if DT_PROP(DT_NODELABEL(quadspi), dual_flash) &&
defined(QUADSPI_CR_DFM)" was used to guard sections specific to
the dual-flash feature. This is quite long and "#ifdef
STM32_QSPI_DOUBLE_FLASH" is now used instead.
Note the presence of QUADSPI_CR_DFM is no more checked. This is not
considered as an issue since when QUADSPI_CR_DFM is not available, the
QSPI hardware doesn't support dual-flash mode so this mode must not be
enabled in the devicetree. With that change, enabling dual-flash mode
when not available causes a compile-time error.
Signed-off-by: Thomas Altenbach <altenbach.thomas@gmail.com>
Add a flash driver that is used to perform flash operations on a flash
chip that is connected to an Andes QSPI controller and is used for XIP
mode.
The driver is as small as possible, because necessary code has to be
placed in RAM. It is not possible to fetch code from flash while
performing erase/write operations.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Turn MCX series into families.
Reasoning:
1. The MCX SOCs are quite different from each other and having them all
under one family in the HWMv2 hierarchy is fruitless because there
are so many differences that it is confusing to try to introduce
family-level code and configs since they would each only apply to a
subset of the series. There is almost nothing that can be shared
between all of them. Which is why there are comments in the MCX
family files saying not to put anything in them. This is a technical
waste.
2. Therefore, turning all of them into families is almost 0 effort and
makes sense. It will allow these different types of MCX to be
further subdivided into series in the future as the MCX portfolio
expands and such division will be necessary as new SOCs within each
letter family are released.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
