| Age | Commit message (Collapse) | Author |
|---|
|
Neha Malcom Francis <[email protected]> says:
Typically we do not enable these configs by default but would still like to
have the option to start building them in our default build flow for
testing. Also there is the added advantage of users being able to see what
is needed in case they choose to enable these features.
Link: https://lore.kernel.org/r/[email protected]
|
|
Add config fragment support for enabling inline ECC and/or BIST on TI K3
supported platforms.
Signed-off-by: Neha Malcom Francis <[email protected]>
|
|
Enable firmware TPM (fTPM) support via OP-TEE for K3 platforms with
MMC hardware. This provides TPM 2.0 functionality through
Microsoft's fTPM Trusted Application running in OP-TEE secure world,
using eMMC RPMB as persistent storage.
fTPM support in U-Boot provides the foundation for measured boot
and disk encryption use cases.
The ARM64 condition ensures these apply only to A53/A72 cores and the
MMC condition ensures fTPM is enabled only on platforms with eMMC
hardware support.
Signed-off-by: Shiva Tripathi <[email protected]>
Acked-by: Andrew Davis <[email protected]>
|
|
Add a common helper function for doing the basic configuration
required for enabling the 32k crystal on some of the TI boards.
Signed-off-by: Vishal Mahaveer <[email protected]>
|
|
Prepare v2026.01-rc4
|
|
Otherwise the custom-cape eeprom (at address 57) reports NACK which
results into "i2c_write: error waiting for data ACK (status=0x116)" and
terminates further scanning.
Signed-off-by: Marian Cingel <[email protected]>
|
|
This patch fixes a boot failure on the AM64x EVM that was introduced when the do_board_detect function was removed during a refactoring.
It restores the do_board_detect function for the AM64x, AM62x, and AM65x boards to ensure the common board detection logic is executed correctly.
Fixes: 804b80288ac ("board: am65x: Use generic AM6x board detection function")
Fixes: ce56e553c31 ("board: am64x: Use generic AM6x board detection functions")
Fixes: ff1b83c095c ("board: am62x: Add support for reading eeprom data")
Signed-off-by: Guillaume La Roque (TI.com) <[email protected]>
|
|
detection"
Guillaume La Roque (TI.com) <[email protected]> says:
This series adds EEPROM board detection support for AM62x and refactors
the board detection code across AM6x family boards to eliminate code
duplication.
The series introduces two new generic functions for AM6x boards:
- do_board_detect_am6(): Reads the on-board EEPROM with fallback logic
to alternate I2C addresses
- setup_serial_am6(): Sets up the serial number environment variable
from EEPROM data
Link: https://lore.kernel.org/r/[email protected]
|
|
Add two new generic functions for AM6x family boards to simplify
board-specific implementations:
- do_board_detect_am6(): Generic board detection function that reads
the on-board EEPROM. It first attempts to read at the configured
address, and if that fails, tries the alternate address
(CONFIG_EEPROM_CHIP_ADDRESS + 1). This provides a common
implementation that can be used across different AM6x boards.
- setup_serial_am6(): Sets up the serial number environment variable
from the EEPROM data. The serial number is converted from
hexadecimal string format to a 16-character hexadecimal
representation and stored in the "serial#" environment variable.
Both functions are protected by CONFIG_IS_ENABLED(TI_I2C_BOARD_DETECT)
and are designed to be used by AM62x, AM64x, AM65x, and other AM6x
family boards.
Reviewed-by: Mattijs Korpershoek <[email protected]>
Signed-off-by: Guillaume La Roque (TI.com) <[email protected]>
|
|
Add CMD_SPL to list of configs implied by TI_COMMON_CMD_OPTIONS. This
allows the use of 'spl export'[1] command for preparing a device-tree
for falcon boot.
[1]:
https://docs.u-boot.org/en/v2025.10/develop/falcon.html#using-spl-command
Signed-off-by: Anshul Dalal <[email protected]>
|
|
Remove the legacy extension board implementation now that all boards
have been converted to use the new UCLASS-based framework. This
eliminates lines of legacy code while preserving functionality
through the modern driver model approach.
Update the bootstd tests, due to the removal of extension hunter.
Signed-off-by: Kory Maincent (TI.com) <[email protected]>
|
|
Migrate TI board cape detection from legacy extension support to the
new UCLASS-based extension board framework.
Signed-off-by: Kory Maincent (TI.com) <[email protected]>
|
|
Clean up and reorganize cape detection code structure for improved
maintainability and readability.
Signed-off-by: Kory Maincent (TI.com) <[email protected]>
|
|
The CAPE_EEPROM_BUS_NUM configuration option was incorrectly depending
on CMD_EXTENSION, which represents the extension board command. However,
the cape scan functionality can be built and used independently of the
command interface through the SUPPORT_EXTENSION_SCAN option.
Change the dependency from CMD_EXTENSION to SUPPORT_EXTENSION_SCAN to
properly reflect that the I2C bus configuration is needed for the cape
scan function itself, not specifically for the command.
Signed-off-by: Kory Maincent (TI.com) <[email protected]>
|
|
Disable cape detection functionality in xPL images to reduce size and
complexity in the early boot stage.
Signed-off-by: Kory Maincent (TI.com) <[email protected]>
|
|
Add CMD_MEMINFO and CMD_MEMINFO_MAP to list of configs implied by
TI_COMMON_CMD_OPTIONS. This allows users to easily view the memory
configuration and the memory maps at runtime.
Signed-off-by: Anshul Dalal <[email protected]>
|
|
Make the fdt_map parameter a pointer to const, since the function only
reads the mapping table. This improves API correctness and allows maps
to live in read-only data.
No functional change intended
Signed-off-by: Bhimeswararao Matsa <[email protected]>
|
|
This reverts both commit 4628730ee6c4 ("mach-k3: add runtime memory
carveouts for MMU table") as well as commit b77066d73261 ("mach-k3: add
dynamic mmu fixups for SPL stage") as some feedback from previous
iterations was missed.
This reverts commit b77066d73261855af406422fbbe28a5d527f4dbf and commit
4628730ee6c40864dbe475e4ca91e47a92f371fe.
Signed-off-by: Tom Rini <[email protected]>
|
|
In u-boot we only provide a single MMU table for all k3 platforms,
this does not scale for devices with reserved memory outside the range
0x9e780000 - 0xa0000000 or for devices with < 2GiB of memory (eg
am62-SIP with 512MiB of RAM).
To properly configure the MMU on various k3 platforms, the
reserved-memory regions need to be queried at runtime from the
device-tree and the MMU table should be updated accordingly.
This patch adds the required fixups to the MMU table (during proper
U-boot stage) by marking the reserved regions as non cacheable and
keeping the remaining area as cacheable.
For the A-core SPL, the 128MiB region starting from SPL_TEXT_BASE
is marked as cacheable i.e 0x80080000 to 0x88080000.
The 128MiB size is chosen to allow for future use cases such as falcon
boot from the A-Core SPL which would require loading kernel image from
the SPL stage. This change also ensures the reserved memory regions that
all exist past 0x88080000 are non cacheable preventing speculative
accesses to those addresses.
Signed-off-by: Anshul Dalal <[email protected]>
|
|
The value of "ETH_ALEN" is defined to 6 in <linux/if_ether.h>. This file
is included in <net.h>. In the places where we had ETH_ALEN but no
direct include of <net.h>, add <linux/if_ether.h>. In the places where
we had a custom name used, make use of ETH_ALEN instead.
Signed-off-by: Tom Rini <[email protected]>
|
|
Add CMD_CACHE to list of configs implied by TI_COMMON_CMD_OPTIONS.
This allows the usage of cache commands from U-Boot prompt.
Signed-off-by: Anshul Dalal <[email protected]>
Reviewed-by: Daniel Schultz <[email protected]>
|
|
Add TI_COMMON_CMD_OPTIONS config options to Sitara K3 boards at
a53 stage since we rely on most of the commands implied for testing
and debugging purposes. Since all commands are now enabled by
default, remove the redundant CMD_* options in the a53 defconfigs.
Also add MMC_REG & MMC_SPEED_MODE_SET useful commands to
TI_COMMON_CMD_OPTIONS.
Signed-off-by: Judith Mendez <[email protected]>
Reviewed-by: Bryan Brattlof <[email protected]>
|
|
This config is causing conflicts with how fdtfile variable is
initialized.
For K3 devices, CONFIG_DEFAULT_DEVICE_TREE= "ti/k3-<board>.dtb".
With CONFIG_TI_FDT_FOLDER_PATH also prefixing "ti", fdtfile is then
"ti/ti/k3-<board>.dtb". This variable is updated when fitImage is
booted and fails to boot due to the parsing error "ti/ti/".
Given that there are no other users of this config other than K3 for
now, it is being removed.
Since am64x, j721e and j721s2 also define a DEFAULT_FDT_FILE, update
them to conform to the DEFAULT_DEVICE_TREE standard.
Signed-off-by: Aashvij Shenai <[email protected]>
|
|
size when ECC is enabled
As there are few redundant functions in board/ti/*/evm.c files, pull
them to a common location of access to reuse and include the common file
to access the functions.
Call k3-ddrss driver through fixup_ddr_driver_for_ecc() to fixup the
device tree and resize the available amount of DDR, if ECC is enabled.
Otherwise, fixup the device tree using the regular
fdt_fixup_memory_banks().
Also call dram_init_banksize() after every call to
fixup_ddr_driver_for_ecc() is made so that gd->bd is populated
correctly.
Ensure that fixup_ddr_driver_for_ecc() is agnostic to the number of DDR
controllers present.
Signed-off-by: Santhosh Kumar K <[email protected]>
Signed-off-by: Neha Malcom Francis <[email protected]>
Reviewed-by: Wadim Egorov <[email protected]>
|
|
Add CMD_NFS to list of configs implied by CONFIG_TI_COMMON_CMD_OPTIONS.
This allows network booting via the NFS protocol from the U-Boot prompt.
Fixes: 10de12570799 ("disable NFS support by default")
Signed-off-by: Neha Malcom Francis <[email protected]>
|
|
Use the new symbol to refer to any 'SPL' build, including TPL and VPL
Signed-off-by: Simon Glass <[email protected]>
|
|
Move snprintf to stdio.h since it is needed by exteranl libraries.
Signed-off-by: Raymond Mao <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Remove <common.h> from this board vendor directory and when needed
add missing include files directly.
Signed-off-by: Tom Rini <[email protected]>
|
|
The file include/eeprom.h is used only in some legacy non-DM I2C EEPROM
access cases. Remove most inclusions of this file as they are not
needed.
Signed-off-by: Tom Rini <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Roger Quadros <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
|
|
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 <[email protected]>
Tested-by: Matwey V. Kornilov <[email protected]>
Reviewed-by: Neha Malcom Francis <[email protected]>
|
|
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 <[email protected]>
|
|
Replace instances of http://www.ti.com with https://www.ti.com
Signed-off-by: Nishanth Menon <[email protected]>
|
|
This old patch was marked as deferred. Bring it back to life, to continue
towards the removal of common.h
Move this out of the common header and include it only where needed.
Signed-off-by: Simon Glass <[email protected]>
|
|
Schema file in YAML must be provided in board/ti/common for validating
input config files and packaging system firmware. The schema includes
entries for rm-cfg, board-cfg, pm-cfg and sec-cfg.
Board config files must be provided in board/ti/<devicename> in YAML.
These can then be consumed for generation of binaries to package system
firmware. Added YAML configs for J721E in particular.
Signed-off-by: Tarun Sahu <[email protected]>
[[email protected]: prepared patch for upstreaming]
Signed-off-by: Neha Malcom Francis <[email protected]>
|
|
This matches how it was done for pre-K3 TI platforms and it allows
us to move the forward declaration out of sys_proto.h.
It also removes the need for K3_BOARD_DETECT as one is free to simply
override the weak function in their board files as needed.
Signed-off-by: Andrew Davis <[email protected]>
Reviewed-by: Christian Gmeiner <[email protected]>
|
|
For non TI boards it is not possible to enable the do_board_detect()
call as TI_I2C_BOARD_DETECT is defined in board/ti/common/Kconfig.
I want to use do_board_detect() to dectect boards and properties based
on some SPI communication with a FPGA.
Signed-off-by: Christian Gmeiner <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
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 bf6376642fe8
("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 d2ab2a2bafd5 ("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, DRA7xx, AM64x
Signed-off-by: Neha Malcom Francis <[email protected]>
Fixes: d2ab2a2bafd5 (board: ti: common: board_detect: Fix EEPROM read quirk for AM6 style data)
Fixes: bf6376642fe8 (board: ti: common: board_detect: Fix EEPROM read quirk)
Tested-By: Matwey V. Kornilov <[email protected]>
|
|
The situation is similar to commit bf6376642fe8 ("board: ti: common:
board_detect: Fix EEPROM read quirk"). This is seen on a variant of
eeproms seen on some BeagleBone-AI64 which now has a mix of both 1 byte
addressing and 2 byte addressing eeproms.
Unlike the am335x (ti_i2c_eeprom_am_get) and dra7
(ti_i2c_eeprom_dra7_get) which use constant data structure which allows
us to do a complete read of the data, the
am6(ti_i2c_eeprom_am6_get) eeprom parse operation is dynamic.
This removes the option of being able to read the complete eeprom data
in one single shot.
Fortunately, on the I2C bus, we do see the following behavior: In 1
byte mode, if we attempt to read the first header data yet again, the
misbehaving 2 byte addressing device acts in constant addressing mode
which results in the header not matching up and follow on attempt at 2
byte addressing scheme grabs the correct data.
This costs us an extra ~3 milliseconds, which is a minor penalty
compared to the consistent image support we need to have.
Reported-by: Jason Kridner <[email protected]>
Fixes: a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address checks first.")
Signed-off-by: Nishanth Menon <[email protected]>
|
|
There are three different kinds of EEPROM possibly present on boards.
1. 1byte address. For those we should avoid 2byte address in order
not to rewrite the data. Second byte of the address can potentially
be interpreted as the data to write.
2. 2byte address with defined behaviour. When we try to use 1byte
address they just return "FF FF FF FF ... FF"
3. 2byte address with undefined behaviour (for instance, 24LC32AI).
When we try to use 1byte address, then their internal read
pointer is changed to some value. Subsequential reads may be
broken.
To gracefully handle both case #1 and case #3 we read all required
data from EEPROM at once (about 80 bytes). So either all the data is
valid or we fallback to 2byte address.
Cc: Nishanth Menon <[email protected]>
Fixes: a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address checks first.")
Reference: https://lore.kernel.org/all/CAJs94Ebdd4foOjhGFu9Bop0v=B1US9neDLxfhgcY23ukgLzFOQ@mail.gmail.com/
Signed-off-by: Matwey V. Kornilov <[email protected]>
Acked-by: Nishanth Menon <[email protected]>
|
|
Do 1 byte address checks first prior to doing 2 byte address checks.
When performing 2 byte addressing on 1 byte addressing eeprom, the
second byte is taken in as a write operation and ends up erasing the
eeprom region we want to preserve.
While we could have theoretically handled this by ensuring the write
protect of the eeproms are properly managed, this is not true in case
where board are updated with 1 byte eeproms to handle supply status.
Flipping the checks by checking for 1 byte addressing prior to 2 byte
addressing check prevents this problem at the minor cost of additional
overhead for boards with 2 byte addressing eeproms.
Signed-off-by: Nishanth Menon <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Due to supply chain issues, we are starting to see a mixture of eeprom
usage including the smaller 7-bit addressing eeproms such as 24c04
used for eeproms.
These eeproms don't respond well to 2 byte addressing and fail the
read operation. We do have a check to ensure that we are reading the
alternate addressing size, however the valid failure prevents us
from checking at 1 byte anymore.
Rectify the same by falling through and depend on header data comparison
to ensure that we have valid data.
Signed-off-by: Nishanth Menon <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
The eeprom data area is much bigger than the data we intend to store,
however, with bad programming, we might end up reading bad records over
and over till we run out of eeprom space. instead just exit when 10
consecutive records are read.
Signed-off-by: Nishanth Menon <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
The BeagleBone platforms all use a common mechanism to discover and
identify extension boards (called "capes"): each extension board has an
I2C-connected EEPROM describing itself.
This patch implements a generic extension_scan_board() feature that can
be used by all BeagleBone platforms to read those I2C EEPROMs and fill
in the list of "extension" structures.
Following commits will enable this common logic on two BeagleBone
platforms.
Signed-off-by: Kory Maincent <[email protected]>
|
|
Use CONFIG_IS_ENABLED() macro, which provides more convenient
way to check $(SPL)DM_I2C/$(SPL)DM_I2C_GPIO configs
for both SPL and U-Boot proper.
CONFIG_IS_ENABLED(DM_I2C) expands to:
- 1 if CONFIG_SPL_BUILD is undefined and CONFIG_DM_I2C is set to 'y',
- 1 if CONFIG_SPL_BUILD is defined and CONFIG_SPL_DM_I2C is set to 'y',
- 0 otherwise.
All occurences were replaced automatically using these bash cmds:
$ find . -type f -exec sed -i
's/ifndef CONFIG_DM_I2C/if !CONFIG_IS_ENABLED(DM_I2C)/g' {} +
$ find . -type f -exec sed -i
's/ifdef CONFIG_DM_I2C/if CONFIG_IS_ENABLED(DM_I2C)/g' {} +
$ find . -type f -exec sed -i
's/defined(CONFIG_DM_I2C)/CONFIG_IS_ENABLED(DM_I2C)/g' {} +
$ find . -type f -exec sed -i
's/ifndef CONFIG_DM_I2C_GPIO/if !CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} +
$ find . -type f -exec sed -i
's/ifdef CONFIG_DM_I2C_GPIO/if CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} +
$ find . -type f -exec sed -i
's/defined(CONFIG_DM_I2C_GPIO)/CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} +
Reviewed-by: Heiko Schocher <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Igor Opaniuk <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Priyanka Jain <[email protected]>
|
|
There shouldn't be a need to call additional i2c read if above failed
already. Based on comment it should be enough to try to detect legacy
boards which are mentioned in the comment.
Fixes: 2463f6728e82 ("ti: common: board_detect: Allow DM I2C without CONFIG_DM_I2C_COMPAT")
Fixes: 0bea813d0018 ("ARM: omap-common: Add standard access for board description EEPROM")
Signed-off-by: Michal Simek <[email protected]>
|
|
Current usage of eeprom apis produce a build failure when
CONFIG_TI_I2C_BOARD_DETECT is not defined. Add stub function for these
apis to avoid build failures.
Reviewed-by: Suman Anna <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
|
|
When building this code with clang-10 a number of warnings will be
generated along the lines of:
warning: address of array 'ep->version' will always evaluate to 'true'
Convert these checks to checking the strlen of the part of the array we
care about. As this array will be null terminated previously by us,
this is safe.
Cc: Lokesh Vutla <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Lokesh Vutla <[email protected]>
|
|
Move this uncommon header out of the common header.
Signed-off-by: Simon Glass <[email protected]>
|
|
Move this header out of the common header.
Signed-off-by: Simon Glass <[email protected]>
|
