Volatile configuration register are a different set of configuration
registers, i.e. they differ from the status registers. A different
SPI instruction is required to write to these registers. Any changes
to the Volatile Configuration Register get transferred directly to
the Internal Configuration Register and instantly reflect on the
device operation.
In Winbond W35N01JW, these volatile configuration register must be
configured in order to switch to Octal DTR SPI mode.
Add support for writing to volatile configuration registers using a
new WRITE_VCR_OP template.
Datasheet:
https://www.winbond.com/export/sites/winbond/datasheet/W35N01JW_Datasheet_Brief.pdf
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Enable Octal DTR SPI mode, i.e. 8D-8D-8D mode, if the SPI NAND flash
device supports it. Mixed OSPI (1S-1S-8S & 1S-8S-8S), mixed DTR modes
(1S-1D-8D), etc. aren't supported yet.
The method to switch to Octal DTR SPI mode may vary across
manufacturers. For example, for Winbond, it is enabled by writing
values to the volatile configuration register. So, let the
manufacturer's code have their own implementation for switching to
Octal DTR SPI mode.
Check for the SPI NAND device's support for Octal DTR mode using
spinand flags, and if the data_ops and ctrl_ops are 8D-8D-8D, call
change_mode() manufacturer op. If the SPI controller doesn't
supports these modes, the selected data_ops and ctrl_ops will
prevent switching to the Octal DTR mode. And finally update the
spinand protocol and ctrl_ops on success.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
The data_ops_variants and ctrl_ops_variants defined in manufacturer's
code are required again when changing flash modes, because they hold
the op templates for the new protocol. It would be useful to have a
pointer to the device description entry i.e. probed flash's
spinand_info table in the spinand_device struct itself.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Introduce change_protocol() manufacturer_op to let the vendor
provide the implementation of switching of SPI IO modes.
The method to switch to different SPI IO mode may vary across
manufacturers. For example, for Winbond, Octal DTR is enabled by
writing values to the volatile configuration register. So, let the
manufacturer's code have their own implementation for switching to
any given SPI IO mode. Manufacturer's code need to take care, if
the requested protocol change is allowed/needed and how to apply
it.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Add ctrl_ops_variants, which can be used by the manufacturers' codes
to define their SPI control operation variants. Add a macro to easily
define ctrl_ops_varinats. This can be used to list out all the
supported ctrl ops with their respective protocols by the vendors.
Add spinand_select_ctrl_ops_variant() helper function to search for
a supported ctrl_ops variant with the required SPI protocol in a given
list of variants.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Make use of the ctrl_ops struct, to introduce the usage of templates
in non-page read/write operations as well. These templates are
initialized at the probe time or at SPI modes switches.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Add default ctrl_ops in the core, which can be used when the op
templates are commonly used ones. Till now, the core had used only
fixed ctrl operations, so the default 'ctrl_ops' is just these ops
macros initialized with default arguments. The default protocol is
1S-1S-1S.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
'ctrl_ops' are op templates for non-page read/write operations,
which are: reset, get_feature, set_feature, write_enable, block_erase,
page_read and program_execute ops. The 'ctrl_ops' struct contains in it
op templates for each of this op, as well as enum spinand_protocol
denoting protocol of all these ops.
We require these new op templates because of deviation in standard
SPINAND ops by manufacturers and also due to changes when there is a
change in SPI protocol/mode. This prevents the core from live-patching
and vendor-specific adjustments in ops.
Define 'ctrl_ops', add macros to initialize it and add it in
spinand_device.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Manufacturers have been deviating from the standard SPI operations for
NAND flashes. There have been variations in non-page read/write
instructions too. Additionally, operations, including non-page r/w ops,
vary when flash is in different SPI mode, eg. Octal DTR.
To avoid live-patching in hot-paths or vendor-specific adjustment,
it is better to have a set of operation templates and variants for
non-page read/write operations as well. These would get initialized at
the probe time or when flash changes modes. These would be called
'ctrl_ops'.
To make code better understandable, create two types of op templates
which are: data_ops and ctrl_ops. Reason for having two different type
of templates is the difference in their use cases i.e. it is possible
to have ops of different protocol for read/write/update simulatneously
in the data_ops, but all the ops in the ctrl_ops follow same protocol.
Rename op_templates to data_ops, and the ctrl_ops would be introduced
in later commits.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Unlike Dual and Quad SPI modes flashes, Octal DTR SPI NAND flashes
require all instructions to be made in 8D-8D-8D protocol when the
flash is in Octal DTR mode. Hence, storing the current SPI IO mode
becomes necessary for operating the flash and switching between modes.
Store the current SPI IO mode in the spinand struct using a
spinand_protocol enum. This would act as a flag, denoting that the
core should use the given SPI protocol all types of flash operations.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Define new op templates for reset, write enable, set_feature,
get_feature, block_erase, read/write page operations for Octal DTR SPI
mode. These templates will be used in data_ops and ctrl_ops for
performing all flash operations.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Setting dtr field of spi_mem_op is used when creating templates for
DTR ops in spinand.h. Also, 2 bytes cmd phases are required when
operating in Octal DTR SPI mode.
Create new templates for dtr mode cmd, address, dummy and data phase
in spi_mem_op, to set the dtr field to 1 and also allow passing the
nbytes for the cmd phase.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Looks like PROGRAM LOAD (AKA write cache) does not necessarily reset
the cache content to 0xFF (depends on vendor implementation), so we
must fill the page cache entirely even if we only want to program the
data portion of the page, otherwise we might corrupt the BBM or user
data previously programmed in OOB area.
commit mtd: spinand: Handle the case where PROGRAM LOAD does not reset
the cache ("13c15e07eedf26092054c8c71f2f47edb8388310")
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
AM62x-SK supports booting up from SPI NAND flash (W35N01JW).
Add support to allow booting using MTD SPI NAND framework.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Introduce support for using MTD subsystem for loading images from
memory flashes. This will provide the support of using mtd functions
which are abstracted over the type of flash being used, to load the
boot images from the flash.
Currently, add support for only SPI NAND flashes. This can be extended
to all other flash types, when required.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Only RAW NANDs are supported in the SPL, so create a new Kconfig config
for building SPI NAND subsystem in the SPL build using
SPL_NAND_SPI_SUPPORT Kconfig option.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
update_cache op only updates the transmitted data on the page, rest of
the page remains same as before. Whereas write_cache op programs full
page completely. update_cache op can also be used to perform the task
of full page program also (just like write_cache op).
update_cache op works more stably on u-boot than write cache op, and is
also used for all write operations in Linux MTD SPI NAND driver.
So, use update cache op instead of write cache op for writing to flash.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
cadence-quadspi has a builtin Auto-HW polling funtionality using which
it keep tracks of completion of write operations. When Auto-HW polling
is enabled, it automatically initiates status register read operation,
until the flash clears its busy bit.
cadence-quadspi controller doesn't allow an address phase when
auto-polling the busy bit on the status register. Unlike SPI NOR
flashes, SPI NAND flashes do require the address of status register
when polling the busy bit using the read register operation. As
Auto-HW polling is enabled by default, cadence-quadspi returns a
timeout for every write operation after an indefinite amount of
polling on SPI NAND flashes.
Disable Auto-HW polling completely as the spi-nor core, spinand core,
etc. take care of polling the busy bit on their own.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Although this is not strictly needed as the tiboot3.bin file on J721e
does not contain SYSFW like other platforms, renaming this way matches
the others and helps simplify integration layers.
Signed-off-by: Andrew Davis <afd@ti.com>
Although this is not strictly needed as the tiboot3.bin file on AM65x
does not contain SYSFW like other platforms, renaming this way matches
the others and helps simplify integration layers.
A symlink is added to keep the default for AM65x as GP.
Signed-off-by: Andrew Davis <afd@ti.com>
The name of the tiboot3.bin should match the SYSFW contents. This makes
it easy to figure out what SYSFW was used for each and matches how
k3-image-gen used to name these files.
Signed-off-by: Andrew Davis <afd@ti.com>
The AM62x LP SK board is derivative of AM62x SK but has different
set of properies. It requires a differnt binary at A53 SPL and U-boot.
Add am62x_lpsk_a53_defconfig to enable support of AM62x LP SK at
A53 SPL and U-boot stage.
Signed-off-by: Nitin Yadav <n-yadav@ti.com>
The AM62x LP SK board is derivative of AM62x SK but has
different set of properies. It need a differnt binary at
R5 SPL. Add am62x_lpsk_r5_defconfig to enable support of
AM62x LP SK at R5 SPL stage.
Signed-off-by: Nitin Yadav <n-yadav@ti.com>
Add macro to enable support of board names of AM62x SK
and AM62x LP SK at different stage of bootloader. Add
do_board_detect() and supporting API's to read EEPROM for
detection of correct board identities. Also restrict
multiple EEPROM reads by verifying if EEPROM is already
read.
Signed-off-by: Nitin Yadav <n-yadav@ti.com>
Now that single defconfig is getting used to boot AM62x SK and
AM62x LP SK, the default device tree will not work for selecting
dtb for kernel. Update the findfdt env to select right dtb based
on board_name env variable.
Signed-off-by: Nitin Yadav <n-yadav@ti.com>
The AM62x LP SK board has separate set of device tree. Update
Makefile with k3-am62-r5-lp-sk.dts and k3-am62-lp-sk.dts device
tree to add support of AM62x LP SK.
Signed-off-by: Nitin Yadav <n-yadav@ti.com>
The AM62x LP SK board is similar to AM62x SK board, but
has a own set of attributes that requires different device
tree on each stage of bootloader. These dt changes add
support for AM62x LP SK at R5 SPL.
Signed-off-by: Nitin Yadav <n-yadav@ti.com>
To prepare for upcoming derivative boards based on the
AM625 SK, sync the dts and dtsi files for this board so
that the derivative boards will inherit and retain only
those parts that are different in the current dts file.
Signed-off-by: Nitin Yadav <n-yadav@ti.com>
The AM62x LP SK board is similar to the AM62x SK board,
but has some significant changes that requires different
device tree.
The differences are mainly:
- AM62x SoC in the AMC package that meets AECQ100 automotive standard.
- LPDDR4 versus DDR4 on the AM62x SK.
- TPS65219 PMIC instead of discrete regulators.
- IO expander pin names are wired differently.
- Second ethernet port is currently disabled as the boards do not have
the part physically installed.
- OSPI NAND vs OSPI NOR.
- No WLAN chip instead a SDIO M.2 connector.
Signed-off-by: Nitin Yadav <n-yadav@ti.com>
Earlier documentation specified builds for generating bootloader images
using an external TI repository k3-image-gen and core-secdev-k3. Modify
this to using the binman flow so that user understands how to build the
final boot images.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Since binman is used to package bootloader images for all K3 devices, we
do not have to rely on the earlier methods to package them.
Scripts that were used to generate x509 certificate for tiboot3.bin and
generate tispl.bin, u-boot.img have been removed.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Move to using binman to generate tispl.bin which is used to generate the
final flash.bin bootloader for iot2050 boards.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Support added for HS and GP boot binaries for AM62ax.
tiboot3.bin, tispl.bin and u-boot.img: For HS-SE devices
tiboot3.bin_fs, tispl.bin and u-boot.img: For HS-FS devices
tiboot3.bin_unsigned, tispl.bin_unsigned and u-boot.img_unsigned: For GP
devices
It is to be noted that the bootflow followed by AM62ax requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
* TIFS
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* DM
* ATF
* OPTEE
* A72 SPL
* A72 SPL dtbs
u-boot.img:
* A72 U-Boot
* A72 U-Boot dtbs
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Support added for HS and GP boot binaries for AM62
tiboot3.bin, tispl.bin and u-boot.img: For HS-SE devices
tiboot3.bin_fs, tispl.bin and u-boot.img: For HS-FS devices
tiboot3.bin_unsigned, tispl.bin_unsigned, u-boot.img_unsigned: For GP
devices
It is to be noted that the bootflow followed by AM62 requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
* TIFS
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* DM
* ATF
* OPTEE
* A72 SPL
* A72 SPL dtbs
u-boot.img:
* A72 U-Boot
* A72 U-Boot dtbs
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Support added for HS and GP boot binaries for J721S2.
tiboot3.bin, tispl.bin and u-boot.img: For HS-SE devices
tiboot3.bin_fs, tispl.bin and u-boot.img: For HS-FS devices
tiboot3.bin_unsigned, tispl.bin_unsigned, u-boot.img_unsigned: For GP
devices
It is to be noted that the bootflow followed by J721S2 requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
* TIFS
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* DM
* ATF
* OPTEE
* A72 SPL
* A72 SPL dtbs
u-boot.img:
* A72 U-Boot
* A72 U-Boot dtbs
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Support added for HS and GP boot binaries for AM64x.
tiboot3.bin, tispl.bin and u-boot.img: For HS-SE devices
tiboot3.bin_fs, tispl.bin and u-boot.img: For HS-FS devices
tiboot3.bin_unsigned, tispl.bin_unsigned, u-boot.img_unsigned: For GP
devices
Note that the bootflow followed by AM64x requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
* sysfw
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* ATF
* OPTEE
* A53 SPL
* A53 SPL dtbs
u-boot.img:
* A53 U-Boot
* A53 U-Boot dtbs
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Apurva Nandan
Andrew Davis
Neha Malcom Francis
Nitin Yadav