Can be used only once the SiM3U SoC support has been added.
Developed-by: Michael Zimmermann
Signed-off-by: Reto Schneider <reto.schneider@husqvarnagroup.com>
Some flash/memc drivers like flexspi will want to default the
value of the log level to off to avoid RWW hazard while XIP,
to do this, the logging template must be sourced after the driver
kconfig files so that the default value from the driver is able
to be checked, since logging template introduces an unconditional
default otherwise.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
The commit adds two new API calls:
- flash_fill - that allows to fill selected part of device with
specified value;
- flash_flatten - that allows to erase or fill device with
erase_value, depending on whether driver for the device provides
erase callback.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
The commit adds and no_explicit_erase capability to flash_parameters,
that indicates whether device is program-erase type device; such
devices, like Flash type devices, require erase prior to writing
random data at any previously programmed location.
This capability should only be set by drivers.
The flash_params_get_erase_cap() function has been added, for parsing
flash_parameters object to obtain erase capabilities of device.
The function returns capabilities as combination of bits representing
them. Currently it will return:
0 -- no erase capabilities
FLASH_ERASE_C_EXPLICIT -- erase required before write of random data.
Additional capabilities have been reserved but are not yet used.
There are following Kconfig options added:
FLASH_HAS_EXPLICIT_ERASE
FLASH_HAS_NO_EXPLICIT_ERASE
that should be selected by device driver to indicate whether
devices served by driver needs erase prior to write.
The above Kconfigs are used to figure out whether app is built
for hardware that requires erase prior to write.
They can be also used to detect that it is attempted to build
some subsystem that will not work with provided hardware, for example
file system that has not been prepared to work with devices that
do not require erase.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
Introduce a XSPI driver to cover the common XSPI peripherals
of the stm32 mcu: X is for single or quad or octo or hexa
SPI bus access to external memories
DMA not supported in this version
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Add Nuvoton numaker series flash memory controller(RMC) with erase,
read & write features of soc-flash.
Signed-off-by: cyliang tw <cyliang@nuvoton.com>
Added a simple driver for RRAM. It is implemented as a flash driver,
because the "RRAM eFlash" macro obeys flash-like constraints.
Although users are not required to erase before write.
Signed-off-by: Jakub Zymelka <jakub.zymelka@nordicsemi.no>
Do not enable subsystem/driver shell modules by default and stop abusing
CONFIG_SHELL_MINIMAL, which is internal to the shell subsystem, to decide
when to enable a driver shell.
The list of shell modules has grown considerably through the
years. Enabling CONFIG_SHELL for doing e.g. an interactive debug session
leads to a large number of shell modules also being enabled unless
explicitly disabled, which again leads to non-negligible increases in
RAM/ROM usage.
This commit attempts to establish a policy of subsystem/driver shell
modules being disabled by default, requiring the user/application to
explicitly enable only those needed.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add support for flash NOR memory devices on a NXP S32 QSPI bus. The
driver uses a fixed LUT configuration assuming a default standard page
size and erase types, and allows to select between multiple read/program
instructions/modes. It is also possible to read the flash device
characteristics from the device at run-time as long as the memory is
JESD216 compatible, providing more flexibility.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
Add Nuvoton numaker series flash memory controller(FMC) with erase,
read & write features of soc-flash. Also update Nuvoton manifest
to include zephyrproject-rtos/hal_nuvoton#6.
Signed-off-by: cyliang tw <cyliang@nuvoton.com>
This CL attempts to implement npcx's flash driver instead of the
original one (npcx spi driver plus spi_nor flash driver).
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
- Added initial version of Infineon CAT1 Flash driver
- Added binding file for infineon,cat1-flash-controller.yaml
- Added overlays for subsys/nvs and drivers/flash_shell
to support cy8cproto_063_ble, cy8cproto_062_4343w boards
- Defined erase-block-size in PSoC6 MPN dtsi.
Signed-off-by: Sreeram Tatapudi <sreeram.praveen@infineon.com>
Unify the drivers/*/Kconfig menuconfig title strings to the format
"<class> [(acronym)] [bus] drivers".
Including both the full name of the driver class and an acronym makes
menuconfig more user friendly as some of the acronyms are less well-known
than others. It also improves Kconfig search, both via menuconfig and via
the generated Kconfig documentation.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Besides of standard flash operations like write or erase, flash
controllers also support additional features like write protection or
readout protection. These features are not available in every flash
controller, what's more controllers can implement it in a different way.
It doesn't make sense to add a separate flash API function for every
flash controller feature, because it could be unique (supported on small
number of flash controllers) or the API won't be able to represent the
same feature on every flash controller.
Extended operation interface provides flexible way for supporting flash
controller features. Code space is divided equally into Zephyr codes
(MSb == 0) and vendor codes (MSb == 1). This way we can easily add
extended operations to the drivers without cluttering the API or
problems with API incompatibility. Extended operation can be promoted
from vendor codes to Zephyr codes if the feature is available in most
flash controllers and can be represented in the same way.
Signed-off-by: Patryk Duda <pdk@semihalf.com>
This supports three types GD32 FMC flash memory. GD32 FMC v1,
GD32 FMC v2 and GD32 FMC v3.
GD32 FMC v1 for small flash memory, flash size can be up to 512KB.
GD32 FMC v2 for large flash memory, flash size can be up to 3072KB.
GD32 FMC v3 not use page but sector as minimum block, flash size can
be up to 3072KB.
Signed-off-by: HaiLong Yang <hailong.yang@brainco.cn>
This adds flash driver for Renesas SmartBond(tm) family.
This technically uses QSPI controller but since default and most
commonly used configuration is to boot from external QSPI flash (DA1469x
do not have built-in flash) and that flash is mapped into memory space,
it can be represented as internal flash.
Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@codecoup.pl>
Signed-off-by: Ben Lauret <ben.lauret.wm@renesas.com>
This includes a basic driver for built-in flash on the Texas Intruments
SimpleLink CC13xx/CC26xx SoC series.
The driver makes use of driverlib HAL from TI's SDK and was tested on
two LaunchXL development boards with CC1352R and CC2652R SoCs:
- CC1352R1 LaunchXL
- CC26x2R1 LaunchXL
Tests were done using:
- flash shell sample (samples/drivers/flash_shell)
- littlefs filesystem sample (samples/subsys/fs/littlefs)*
- MCUboot (bootloader/mcuboot/boot/zephyr)*
* additional changes in DTS for the boards were required (partitions
table) and are not part of this changeset (will be introduced later)
Some additional information about the implementation:
1. TI's Technical Reference Manual for CC13x2 and CC26x2 points out that
"An individual 64-bit word can be programmed to change bits 1 to 0"
but it seems this 'alignment' requirement is handled internally by
the ROM function and thus 'write-block-size' is set to 1.
2. Interrupts, VIMS and line buffers are disabled during flash content
update (write or erase) and restored afterwards as recommended by TI.
3. Only RAM to flash write is supported (source of data to be written to
flash can't point to flash).
4. The driver doesn't take care of flash sector protection disable as
that functionality is handled by CCFG. Write or erase requests which
refer to a protected area will fail.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
This is the stm32 octospi driver based on the exisitng quadspi
for stm32 devices and source code from the STM32Cube.
This drivers initialized the peripheral and the NOR memory
in SPI or OctoSPI mode with STR or DTR data Transfer rates.
The NOR-flash can provide the SDFP table directly (if supported)
or through the DeviceTree.
Limitation: no DMA transfer.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
According to Kconfig guidelines, boolean prompts must not start with
"Enable...". The following command has been used to automate the changes
in this patch:
sed -i "s/bool \"[Ee]nables\? \(\w\)/bool \"\U\1/g" **/Kconfig*
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Refactors all of the on-chip flash drivers to use a shared driver class
initialization priority configuration, CONFIG_FLASH_INIT_PRIORITY, to
allow configuring flash drivers separately from other devices. This is
similar to other driver classes like I2C and SPI.
The default is set to CONFIG_KERNEL_INIT_PRIORITY_DEVICE to preserve the
existing default initialization priority for most drivers.
Driver-specific options for SPI-based flash drivers are left intact
because they need to be initialized at a different priority than on-chip
flash drivers.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
Add flash driver for it8xxx2. The driver can implement
flash read, write and erase that will be mapped to the
ram section for executing.
TEST="flash write 0x80000 0x10 0x20 0x30 0x40 ..."
"flash read 0x80000 0x100"
"flash erase 0x80000 0x1000"
Signed-off-by: Tim Lin <tim2.lin@ite.corp-partner.google.com>
Older LPC platforms use Flash IAP with a command style firmware command.
Tested on LPC54114 platform.
Signed-off-by: Andrei Gansari <andrei.gansari@nxp.com>
Add support for DMA based STM32 QSPI NOR flash controller.
Driver configures both NOR flash and also QSPI hardware block.
Reuses existing jesd216 library.
QSPI hardware block handling is done through the use of Cube HAL API.
This requires the use of HAL interface also for DMA besides zephyr
DMA driver.
Zephyr DMA driver is used only for IRQ routing while HAL driver
handles the IP block. To achieve this it is required to:
-Configure both Cube and Zephyr drivers at init.
-Inform Zephyr driver that current channel handling will be done
by another instance and only a limited configuration should be done.
For this last part, a unused parameter is overridden in order to
transmit the information.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Signed-off-by: Piotr Mienkowski <piotr.mienkowski@gmail.com>
The spi_flash_w25qxxdv driver has been superseded by the generic
spi_nor driver for over a year. The only non-refactoring change to
the W25Q driver in the last 18 months was done to support a backport
to 1.14.
All devices supported by spi_flash_w25qxxdv driver are expected to be
supported by the spi_nor driver, using the standard `jedec,spi-nor`
devicetree compatible. No in-tree devicetree files make use of this
driver.
Remove the confusion about which driver to select by removing the
unmaintained redundant driver.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Expose the internal JESD216 function used to read data from the SFDP
region, and another function to read the JEDEC ID.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Some flash drivers are capable of issuing a JESD216 READ_SFDP command
to read serial flash discoverable parameters. Allow applications and
utilities access to that capability where it's supported.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
The spi_nor flash interface was designed for flash devices that use a
standard SPI interface to devices that are compatible with the Micron
M25P80 serial flash, identified in Linux as compatible jedec,spi-nor.
The JEDEC Serial Flash Discoverable Parameters standard (JESD216) was
designed to allow these devices to be self-describing. As we are
increasingly being asked to support flash memories that do not use
"standard" erase sizes or commands we need data structures and helper
functions to extract information about a flash interface at runtime.
For some of these devices the commands hard-coded in the current
implementation are simply wrong.
Define generic structures that support the SFDP hierarchy and the core
Basic Flash Parameters table. The description will also support
SPI-NAND and xSPI devices that conform to the JESD216 standards.
Add bitfield values and helper functions to extract some information
that drivers might need from JESD216 fields. At this time only
information that is likely to be used is extracted; more may be added
in the future.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
If shell is enabled then enable all sub-shells if their dependencies are
satisfied. This was done for some modules and subsystems but was not
consistent.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add a driver that can handle several instances of AT45 family chips,
which are enabled by specifying DT nodes for them with the "compatible"
property set to "atmel,at45" and other required properties like JEDEC
ID, chip capacity, block and page size etc. configured accordingly.
The driver is only capable of using "power of 2" binary page sizes in
those chips and at initialization configures them to work in that mode
(unless it is already done).
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Most JEDEC NOR flash devices uses not only typical SPI mode
(MISO,MOSI,SCK and CS), but also QSPI mode (IO0,IO1,IO2,IO3,SCK and CS).
QSPI mode uses more data lines and as a result provide higher
throughput. If this were not enough, Nordic chips provide
hardware acceleration for read/write/erase functions, what
gives significant performance boost.
It does a lot of things "behind the scene", i.e when user has written
some data to the flash and would like to read them back, it has to wait
until the flash is ready by reading WIP bit in Status Register.
This driver does it automatically.
Signed-off-by: Kamil Lazowski <Kamil.Lazowski@nordicsemi.no>
Use this short header style in all Kconfig files:
# <description>
# <copyright>
# <license>
...
Also change all <description>s from
# Kconfig[.extension] - Foo-related options
to just
# Foo-related options
It's clear enough that it's about Kconfig.
The <description> cleanup was done with this command, along with some
manual cleanup (big letter at the start, etc.)
git ls-files '*Kconfig*' | \
xargs sed -i -E '1 s/#\s*Kconfig[\w.-]*\s*-\s*/# /'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
