Introduce the basic files needed to support the am62px family of SoCs
Co-developed-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Bryan Brattlof <bb@ti.com>
With the latest TIFS firmware, an additional virtual interrupt and
event is reserved for TIFS usage on am62x and am62ax devices.
Update the rm-cfg to reflect this new reservation.
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
TI K3 J784S4 and AM69 are new additions to the K3 SoC family.
Add documentation about the J784S4 EVM and AM69 SK.
Signed-off-by: Dasnavis Sabiya <sabiya.d@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> # AM69-SK
Introduce the base dts files needed for u-boot or to augment the linux
dtbs for use in the u-boot-spl and u-boot binaries.
Signed-off-by: Dasnavis Sabiya <sabiya.d@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> # AM69-SK
Introduce the base dts files needed for u-boot or to augment the linux
dtbs for use in the u-boot-spl and u-boot binaries.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
[ add binman and ddr dtsi files ]
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Signed-off-by: Dasnavis Sabiya <sabiya.d@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> # AM69-SK
Add board files for J784S4 EVM.
SYS_DISABLE_DCACHE_OPS is selected in the Kconfig because
J784S4/AM69 are a coherent architecture at A72 level by
MSMC support.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Dasnavis Sabiya <sabiya.d@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> # AM69-SK
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".
While at this, replace findfdt in environment with a warning as it is no
longer needed.
Reviewed-by: Jonathan Humphreys <j-humphreys@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".
While at this, replace findfdt in environment with a warning as it is no
longer needed.
Reviewed-by: Jonathan Humphreys <j-humphreys@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".
While at this, replace findfdt in environment with a warning as it is no
longer needed.
Reviewed-by: Jonathan Humphreys <j-humphreys@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".
While at this, replace findfdt in environment with a warning as it is no
longer needed.
Reviewed-by: Jonathan Humphreys <j-humphreys@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
Stop using the findfdt script and switch to setting the fdtfile from
C code.
While at this, replace findfdt in environment with a warning as it is
no longer needed
Reviewed-by: Jonathan Humphreys <j-humphreys@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
Stop using the findfdt script and switch to setting the fdtfile from
C code.
While at this, replace findfdt in environment with a warning as it is
no longer needed
Reviewed-by: Jonathan Humphreys <j-humphreys@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
Introduce a common fdt operations library for basic device tree
operations that are common between various boards.
The first library to introduce here is the capability to set up
fdtfile as a standard variable as part of board identification rather
than depend on scripted ifdeffery.
Reviewed-by: Jonathan Humphreys <j-humphreys@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
Add missing board/ti/common/Kconfig references for the platforms that
missed it. The intent is for the common Kconfig to be usable across TI
reference boards as required.
Reported-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Devarsh Thakkar <devarsht@ti.com> says:
Move video memory reservation for SPL at end of RAM so that it does
not interefere with reservations for next stage so that the next stage
need not have holes in between for passed regions and instead it can
maintain continuity in reservations.
Also catch the bloblist before starting reservations to avoid the same
problem.
While at it, also fill missing fields in video handoff struct before
passing it to next stage.
This is as per discussions at :
For moving SPL framebuffer reservation at end of RAM:
https://lore.kernel.org/all/CAPnjgZ3xSoe_G3yrqwuAvoiVjUfZ+YQgkOR0ZTVXGT9VK8TwJg@mail.gmail.com/
For filling missing video handoff fields :
https://lore.kernel.org/all/CAPnjgZ1Hs0rNf0JDirp6YPsOQ5=QqQSP9g9qRwLoOASUV8a4cw@mail.gmail.com/
Remove video_setup from evm_init sequence since video memory is getting
called at an earlier place to make sure video memory is reserved at
the end of RAM.
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
EEPROM detection logic in ti_i2c_eeprom_get() involves reading
the total size and the 1-byte size with an offset 1. The commit
9f393a2d7af8 ("board: ti: common: board_detect: Fix EEPROM read
quirk for 2-byte") that attempts to fix this uses a wrong pointer to
compare.
The value with one offset is read into offset_test, but the pointer
used to match was still ep, resulting in an invalid comparison of the
values. The intent is to identify bad 2-byte addressing eeproms that
get stuck on the successive reads.
Fixes: 9f393a2d7af8 (board: ti: common: board_detect: Fix EEPROM read quirk for 2-byte)
Signed-off-by: Prasanth Babu Mantena <p-mantena@ti.com>
Tested-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Since commit 69b19ca67bcb ("arm: dts: k3-j721e: Sync with v6.6-rc1"),
the following error message is seen at u-boot
"Sierra init failed:-19"
Probing and initializing the SERDES PHY from
board file is not a clean solution so drop it.
Proper use case should be via PHY_UCLASS APIs.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
The TMDS64EVM [1] ships with AM64X SR2.0 HS-FS chip
and a slightly different board name in the board information
EEPROM header. Support this board.
[1] https://www.ti.com/tool/TMDS64EVM
Gets rid of below message at boot
"Unidentified board claims AM64-EVM in eeprom header"
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Nishanth Menon <nm@ti.com>
Clean up all configuration files to adhere to yamllint rules.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
[trini: Update more yaml files added since this was posted]
Signed-off-by: Tom Rini <trini@konsulko.com>
Suggested-by: Nishanth Menon <nm@ti.com>
In order to make it easier to move on to dropping common.h from code
directly, remove common.h inclusion from the rest of the header file
which had been including it.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
After talking with the author off-list I was reminded that this part of
the series was not supposed to be merged, only parts 1-3 upon further
review.
This reverts commit 58a277c207927530469f0ae56eff7d5f702d5486.
Signed-off-by: Tom Rini <trini@konsulko.com>
The base address of extended DDR does not change across the K3 family.
Setting this per SoC is not needed. Remove this definition to help
remove the last bits from K3 include/configs/*.h files.
Signed-off-by: Andrew Davis <afd@ti.com>
Updates as a result of TIFS core now reserving a virtual interrupt
for enabling interrupts between DM to TIFS core. Because of this
change other virtual interrupt counts decrease by one.
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
Share the MCU GPIO interrupts between A53 core and DM R5 core. Allocating
2 instances each to A53 and DM R5.
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
Update am62ax rm-cfg with allocation entries for C7x core. Following
updates are added for C7x:
- Share split BCDMA tx and rx channels between DM R5 and C7x
- Share rings for split BCDMA tx and rx channels between DM R5 and C7x
- Add Global events and Virtual interrupts for C7x
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
This file is common for all K3, move it out of board/ directory and
into mach-k3. As we need to change the path in k3-binman.dtsi let's
take this opportunity to switch to absolute paths which makes adding
non-TI boards (like Toradex Verdin) not need to override these paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Move the omap3 beagle to the beagle vendor folder representing
BeagleBoard.org platforms.
Suggested-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Move beagleplay support away from ti/am62x to it's own beagle vendor
folder.
This forms the starting point for new beagle platforms added under it's
own board vendor folder.
As part of this create all the associated files with a bare minimum
beagleplay.c file.
Suggested-by: Andrew Davis <afd@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
[trini: Update k3-binman.dtsi to use full path to scheme.yaml now]
Signed-off-by: Tom Rini <trini@konsulko.com>
Add am62x_beagleplay_* defconfig customized for the configuration of
BeaglePlay and drop the config fragments.
This is in preparation for dropping the dependency on ti vendor folder
entirely.
Signed-off-by: Nishanth Menon <nm@ti.com>
Add explicit boot_targets to indicate the specific boot sequence to
follow.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
When config is enabled, the esm dt probe makes sense. Simplify by
dropping board specific checks.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
This file is used to emulate customer keys on TI development board
ecosystems, move it out of board/ directory and into mach-k3. And
change the relative paths to absolute paths in the binman paths.
While at it, drop the reference in verdin-binman file which is
redundant.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Manorit Chawdhry <m-chawdhry@ti.com>
This file is common for all of K3, move it out of board/ directory and
into mach-k3. And change the relative paths to absolute paths in the
binman paths.
While at it, drop the reference in verdin-binman file which is
redundant.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
