| Age | Commit message (Collapse) | Author |
|---|
|
Enable configs required to support OSPI NAND boot.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
Update stack, heap size to max available memory, without this R5 SPL DT
gets corrupted in certain boot modes
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
User can specify/override the NAND partition and UBIFS volume
for booting via ${nbootpart} and ${nbootvolume} variables
respectively.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
AM62A SK has a W35 OSPI NAND connected to OSPI controller. Add DT nodes
for the same.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
Use more conventional naming scheme for NAND partitions
and enable listing of partitions in prompt.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
|
|
User can specify/override the NAND partition and UBIFS volume
for booting via ${nbootpart} and ${nbootvolume} variables
respectively.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
|
|
Flash settings such as Octal-DTR mode and other register configurations
should be resetted before the flash is removed. This would enable
a clean removal and re-plug for later boot stages.
The soft-reset command doesn't restore the flash into 1S mode, so
add support for executing 66h+99h PoR flash reset when in Octal DTR mode.
Datasheet:
https://www.winbond.com/export/sites/winbond/datasheet/W35N01JW_Datasheet_Brief.pdf
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
|
|
Releasing the flash into proper state, after the loading completes,
is important for the next stage bootloader/kernel to be able to use
the MTD device. This would enable to reset the device for fresh
use by next boot stage.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
|
|
Winbond W35N01JW is a SPI NAND flash supporting Octal DTR SPI protocol.
Add op_variants and ctrl_ops_variants for W35N01JW, thus adding all
required Octal DTR ops.
Datasheet:
https://www.winbond.com/export/sites/winbond/datasheet/W35N01JW_Datasheet_Brief.pdf
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
|
|
Add implementation of change_protocol() for Winbond's manufacturer_ops,
that executes octal_dtr_enable() and octal_dtr_disable() according
to requested protocol.
Datasheet:
https://www.winbond.com/export/sites/winbond/datasheet/W35N01JW_Datasheet_Brief.pdf
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
|
|
Add implementation of octal_dtr_enable() and octal_dtr_disable()
manufacturer_ops for Winbond. To switch to Ocatl DTR mode, setting
programmable dummy cycles and SPI IO mode using the volatile
configuration register is required. To function at max 120MHz SPI clock
in Octal DTR mode, 12 programmable dummy clock cycle setting is
required. (Default number of dummy cycle are 8 clocks)
Set the programmable dummy cycle to 12 clocks, and SPI IO mode to
Octal DTR with Data Strobe in the VCR. Also, perform a READ ID
operation in Octal DTR SPI mode to ensure the switch was successful.
To disable Octal DTR mode, restore the VCR registers to their default
values and verify it using READ ID operation.
Datasheet:
https://www.winbond.com/export/sites/winbond/datasheet/W35N01JW_Datasheet_Brief.pdf
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
|
|
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>
|
|
OSPI controller supports all types of op variants in STIG mode,
only limitation being that the data payload should be less than
8 bytes when not using memory banks.
STIG mode is more stable for operations that send small data
payload and is more efficient than using DMA for few bytes of
memory accesses. It overcomes the limitation of minimum 4 bytes
read from flash into RAM seen in DAC mode.
Use STIG mode for all read and write operations that require
data input/output of less than 8 bytes from the flash, and thereby
support all four phases, cmd/address/dummy/data, through OSPI STIG.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
|
|
buswidth and dtr fields in spi_mem_op are only valid when the
corresponding spi_mem_op phase has a non-zero length. For example,
SPI NAND core doesn't set buswidth when using SPI_MEM_OP_NO_ADDR
phase.
Fix the dtr checks in set_protocol() to ignore empty spi_mem_op
phases, as checking for dtr field in empty phase will result in
false negatives.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
|
|
The u-boot ums command models the EVM as a card reader and shows the SD
Card latched on the evm as a memory device in the host PC. The Type - C
dual role port should be used for this functionality. This helps in
automating the linux debugging process.
Enable this command in the defconfig.
Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
|
|
Enable Quality of Service (QoS) blocks for Display SubSystem (DSS), by
servicing the DSS - DDR traffic from the Real-Time (RT) queue. This is
done by setting the DSS DMA orderID to 8.
The C7x and VPAC have been overwhelming the DSS's access to the DDR
(when it was accessing via the Non Real-Time (NRT) Queue), primarily
because their functional frequencies, and hence DDR accesses, were
significantly higher than that of DSS. This led the display to flicker
when certain edgeAI models were being run.
With the DSS traffic serviced from the RT queue, the flickering issue
has been found to be mitigated.
The am62a qos files are auto generated from the k3 resource partitioning
tool.
Section-3.1.12, "QoS Programming Guide", in the AM62A TRM[1], provides
more information about the QoS, with the register descriptions
explanined under the "System Interconnect Registers" in "AM62A TRM
Registers 1" section.
[1] AM62A Tech Ref manual: https://www.ti.com/lit/zip/spruj16
Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
Reviewed-by: Praneeth Bajjuri <praneeth@ti.com>
|
|
EEPROM detection logic in ti_i2c_eeprom_get() involves figuring out
whether addressing is 1-byte or 2-byte. There are currently different
behaviours seen across boards as documented in commit 769893c301ec
("board: ti: common: board_detect: Fix EEPROM read quirk"). Adding to
the list, we see that there are 2-byte EEPROMs that read properly
with 1-byte addressing with no offset.
For ti_i2c_eeprom_am6_get where eeprom parse operation is dynamic, the
earlier commit 1c0d06c606ab ("board: ti: common: board_detect: Fix
EEPROM read quirk for AM6 style data") tried to resolve this by running
ti_i2c_eeprom_get() twice. However this commit along with its former
commit fails on J7 platforms where EEPROM successfully return back the
header on 1-byte addressing and continues to do so until an offset is
introduced. So the second read incorrectly determines the EEPROM as
1-byte addressing.
A more generic solution is introduced here to solve
this issue: 1-byte read without offset and 1-byte read with offset. If
both passes, it follows 1-byte addressing else we proceed with 2-byte
addressing check.
Tested on J721E, J7200
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Fixes: 1c0d06c606ab (board: ti: common: board_detect: Fix EEPROM read quirk for AM6 style data)
Fixes: 769893c301ec (board: ti: common: board_detect: Fix EEPROM read quirk)
|
|
Check if the parent pll rate is indeed set to target rate, if not
fallback adjusting dividers to get within 5% of requested rate
This is required to set correct rate for DDR PLLs on AM62A resulting in
lower DDR bandwidth when measured with lmbench (bw_mem)
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
Now that single defconfig shall be used for booting J721S2 EVM and
AM68 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: Sinthu Raja <sinthu.raja@ti.com>
|
|
Add initial support for device tree that runs on R5.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
|
|
The SK architecture comprises of baseboard and a SOM board. The
AM68 Starter Kit's baseboard contains most of the actual connectors,
power supply etc. The System on Module (SoM) is plugged on to the base
board. Therefore, add support for peripherals brought out in the base
board.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
|
|
AM68 Starter Kit (SK) is a low cost, small form factor board designed
for TIâs AM68 SoC. TIâs AM68 SoC comprises of dual core A72, high
performance vision accelerators, hardware accelerators, latest C71x
DSP, high bandwidth real-time IPs for capture and display. The SoC is
power optimized to provide best in class performance for industrial
applications.
AM68 SK supports the following interfaces:
* 16 GB LPDDR4 RAM
* x1 Gigabit Ethernet interface
* x1 USB 3.1 Type-C port
* x2 USB 3.1 Type-A ports
* x1 PCIe M.2 M Key
* 512 Mbit OSPI flash
* x2 CSI2 Camera interface (RPi and TI Camera connector)
* 40-pin Raspberry Pi GPIO header
SK's System on Module (SoM) contains the SoC, PMIC, DDR and OSPI flash.
Therefore, add support for the components present on the SoM.
Schematics: https://www.ti.com/lit/zip/SPRR463
TRM: http://www.ti.com/lit/zip/spruj28
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
|
|
Add the board_init_f API for SPL and run the platform-required SoC initialization.
Add the functionality for board name-based DTB selection from FIT within SPL. This
will make it easier to utilise one defconfig for both the EVM and the SK.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
|
|
Although the board_init_f API initialises the SoC, the API name is
incorrectly specified and misleads the functionality. This file should
only include k3-specific functionality. Change the API's name to something
more K3-specific and separate the function to make it more modular.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
|
|
Update the board_fit_config_name_match() to choose the right dtb
based on the board name read from EEPROM.
Also restrict multpile EEPROM reads by verifying if EEPROM is already
read
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
|
|
AM68-sk doesn't have any daughter cards, so disable daughter
card probing inside board_late_init() for am68-sk.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
|
|
J721S2 EVM has EEPROM populated at 0x50. AM68 SK has EEPROM populated at
next address 0x51 in order to be compatible with RPi. So start looking
for TI specific EEPROM at 0x50, if not found look for EEPROM at 0x51.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
|
|
Update setup_board_eeprom_env() to choose the right board name
for am68-sk.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
|
|
J721S2 EVM used to store env on eMMC, since EVM and SK uses same
defconfig and there is no eMMC on SK, we need to keep env in an
interface which available on both EVM and SK. So, save env in FAT
partition of MMC SD Card.
Enable defconfigs relevant for storing env on FAT partion of MMC.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
|
|
Enable configs for building multiple dtbs into a single fit image
and load the right dtb for next stage. Add k3-am68-sk-base-board
dtb along with evm dtb inside DTB FIT image. This helps to use same
defconfig for both EVM and SK
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
|
|
Enable configs for building multiple dtbs into a single fit image
and load the right dtb for next stage. This will help to use same
defconfig for both EVM and SK.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
|
|
Add the configs needed for USB DFU support
Signed-off-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
|
|
To ensure we continue to have enough space in our SRAM, split the device
firmware upgrade protocol bootmode into a separate configuration
Signed-off-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
|
|
Add support for USB controllers and enable the USB to boot via DFU
Signed-off-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
|
|
Add DFU arguments to environment settings
Signed-off-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
|
|
Set the USB PHY core voltage to 0.85V
Signed-off-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
|
|
Enable eMMC related configs to support booting from eMMC
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
Enable eMMC node to support booting from on board eMMC
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
