Paresh Bhagat <p-bhagat@ti.com> says:
This series adds support for DM firmware reserved memory fixup in device
tree for K3 SoCs that use separate DM firmware (K3_DM_FW enabled).
The series includes:
1. Fix for phandle corruption in FDT reserved memory fixup
2. Enable OF_SYSTEM_SETUP for AM62D2 to allow device tree fixups
3. Add Kconfig options for DM firmware reserved memory for other K3 SoCs
4. Add DM reserved memory fixup implementation
The main issue being addressed is that the current reserved DDR carveout
for DM firmware in device tree is insufficient to accommodate the DM
firmware binary on AM62A7, and potentially other K3 SoCs in the future.
Currently, the size is only modified for AM62A7 SoC. For rest of SocS
existing values from device tree is taken.
For vendor boards, please verify boot and check for errors if any.
This series depends on dts update for effected devices. If "dm" node is
not found then the existing mechanism creates a new node with same
address, which cause memory overlap issue.
Link: https://lore.kernel.org/r/20260701075021.3626094-1-p-bhagat@ti.com
Add support for fixing up DM firmware reserved memory in the kernel
device tree for K3 SoCs that use separate DM firmware.
The fixup uses the CONFIG_K3_DM_FW_RESERVED_ADDR and
CONFIG_K3_DM_FW_RESERVED_SIZE Kconfig options to update the
reserved-memory node with the correct DM firmware carveout.
Note that the fixup needs DM reserved memory node is to be renamed in
dts. Example memory@9c900000 → dm@9c900000
Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Add Kconfig options for DM firmware reserved memory for K3 SOCs that
support DM firmware (K3_DM_FW enabled)
- K3_DM_FW_RESERVED_ADDR: DM firmware address
- K3_DM_FW_RESERVED_SIZE: DM firmware reserved size
These configs will be used to fixup the kernel device tree's reserved
memory node for DM. Currently the fixup is only done for AM62A7 SoC, as
K3_DM_FW_RESERVED_SIZE is being used to update DM reserved memory from
0xf0000 to 0x1f0000 as the current reserved carveout is insufficient to
accommodate the binary.
For other platforms, the addresses and sizes are based on the existing
device tree reserved memory. If needed for other SoCs, address and size
could be modified in Kconfig.
Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
Enable OF_SYSTEM_SETUP for AM62D2 to ensure FDT fixups are applied to
the dtb before passing to kernel.
Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
Reviewed-by: Anshul Dalal <anshuld@ti.com>
Fix phandle corruption in fdt_fixup_reserved_memory()
The original implementation used a delete/recreate approach:
- Find existing reserved memory node (e.g. tfa@80000000)
- Delete the entire node with fdt_del_node()
- Create new node with fdtdec_add_reserved_memory()
This worked fine for ATF and OPTEE nodes because no other device tree
nodes reference them via phandles but other nodes example DM are
referenced by R5 nodes.
If these nodes are deleted and recreated, it will not have any phandle
property but the nodes referencing it will still contain the old
phandle, causing initialization to fail.
Update nodes in-place instead of delete/recreate to update only the
"reg" property using fdt_setprop().
Fixes: 8b0fc29de0 ("arm: mach-k3: am62: Fixup TF-A/OP-TEE reserved-memory node in FDT")
Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Aristo Chen <aristo.chen@canonical.com> says:
The AM62x family (TI EVMs, phytec phycore, toradex verdin) ships
two or three mutually-exclusive tifsstub variants per tispl.bin FIT
image (tifsstub-hs, tifsstub-fs, tifsstub-gp), all assigned the same
load address 0x9dc00000. The current platform code loads every
variant and discards the wrong ones at runtime by zeroing *p_size in
board_fit_image_post_process() (arch/arm/mach-k3/r5/common.c).
This runtime-filter approach has become a friction point. An earlier
attempt to add FIT-image load-address overlap detection to mkimage
flagged the shared 0x9dc00000 as an apparent conflict, and the
workaround in that series was to shift each tifsstub by 64KB
increments. Bryan Brattlof reviewed that change at the time [1] and
pointed out that the real semantics are "load one of three at
runtime", and that moving the binaries was not necessarily safe given
downstream IPC assumptions about the fixed load address. The series
was ultimately reverted upstream, which leaves the underlying
question open: any future static FIT validator needs a way to
understand that these three images do not actually collide. The same
point is being discussed at the spec level in flat-image-tree issue
#32 [2], where a "mutually-exclusive-group" property has been floated
to express runtime-resolved overlaps to static tooling.
This series fixes the problem structurally without moving any
binaries and without a spec extension. Each board's binman dtsi is
updated so the tispl.bin FIT carries one configuration per security
state (conf-hs-se, conf-hs-fs, conf-gp), each containing only the
matching tifsstub. board_fit_config_name_match() in each affected
board reads the SoC security state via get_device_type() and selects
the correct configuration up front, via a shared helper
k3_fit_config_match_security_state() added in arch/arm/mach-k3/
common.c. Each FIT configuration ends up with exactly one tifsstub at
0x9dc00000, so the overlap goes away from any static validator's
perspective and no platform-specific runtime knowledge is needed to
pick the right firmware.
Series ordering is intentional and bisectable. Patch 1 introduces
the helper, migrates the TI EVMs, and leaves the runtime filter in
place. Phytec phycore and toradex verdin boards still use their old
single-config dtsi at this point, and the runtime filter continues
to do the right thing for them in the meantime. Patch 2 migrates the
phytec phycore-am62 SoMs. Patch 3 migrates the toradex Verdin AM62
modules; their previous board_fit_config_name_match() returned 0
unconditionally, which after the dtsi split would have selected the
first listed configuration regardless of silicon and broken HS-SE
parts, so this patch is also a latent-bug fix on top of the migration.
Patch 4 drops the now-dead runtime filter.
Changes since v1, all addressing review feedback from Anshul Dalal:
1. Patch 1: use strncmp() in k3_fit_config_match_security_state()
instead of strcmp() with a redundant ternary, since the suffix
length is already known.
2. Patches 1, 2 and 3: drop the CONFIG_SPL_LOAD_FIT #if guard
around board_fit_config_name_match() on the TI EVM, phycore
and verdin boards. SPL_LOAD_FIT is always selected on ARCH_K3
and LTO drops the function in any build that does not use it.
3. The move of enum k3_device_type and get_device_type() from
arch/arm/mach-k3/common.h to arch/arm/mach-k3/include/mach/
hardware.h in patch 1 is kept as-is. common.h is currently
mach-k3-internal and is not in the include search path for
board files; making it public would be a larger refactor that
Anshul has offered to take on separately [3].
Patch 4 is unchanged from v1; Acked-by from Neha Malcom Francis and
Reviewed-by from Anshul Dalal collected on v1 are carried forward.
Patch 1 has small non-behavioral changes vs v1, so v1 tags from
Alexander Sverdlin (Reviewed-by), Neha Malcom Francis (Acked-by),
and Akashdeep Kaur (Tested-by) are not carried forward and are
pending re-confirmation against v2.
Boot tested on AM625 SK GP silicon end-to-end through TFA, OP-TEE,
A53 SPL, U-Boot proper, and Linux 6.5. The two "Skipping
authentication on GP device" messages in the SPL banner confirm only
the GP tifsstub variant is present in the selected FIT
configuration; loading any HS variant on GP silicon would fail TIFS
authentication before reaching that point. Building (R5 SPL + A53
SPL + U-Boot proper) was verified clean against v2 on am62x_evm,
phycore_am62x, and verdin-am62 defconfigs.
Akashdeep Kaur tested v1 on AM62PX HS-FS and AM62X HS-SE devices,
including deep-sleep suspend/resume. v2 changes are non-behavioral
so the same code paths exercise as v1, but explicit re-test on v2
would be welcome.
[1] https://lore.kernel.org/u-boot/20250916122244.a7rda2ouhou47hp7@bryanbrattlof.com/
[2] https://github.com/open-source-firmware/flat-image-tree/issues/32
[3] https://lore.kernel.org/u-boot/DJG933DITHOO.G8ER04I2UPWX@ti.com/
Link: https://lore.kernel.org/r/20260623141540.618272-1-aristo.chen@canonical.com
With all AM62x family boards (TI EVMs, phytec phycore, toradex
verdin) now using per-security-state FIT configurations and selecting
the right one via board_fit_config_name_match(), the runtime filter
in board_fit_image_post_process() that zero'd out *p_size for the
wrong tifsstub variant is no longer reached. Only one tifsstub
variant is present in the selected FIT configuration, and it is
always the correct one for the current silicon.
Drop the filter so board_fit_image_post_process() simply debug-logs
the variant name and returns.
Acked-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Anshul Dalal <anshuld@ti.com>
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Use the k3_fit_config_match_security_state() helper introduced in the
earlier "arm: k3: select tifsstub via board_fit_config_name_match"
patch to pick the right tifsstub variant on Verdin AM62 and AM62P
SoMs at FIT config selection time.
The k3-am625-verdin-wifi-dev-binman.dtsi and
k3-am62p5-verdin-wifi-dev-binman.dtsi FIT images are split into
per-security-state configurations (conf-hs-se, conf-hs-fs), and
board_fit_config_name_match() in each verdin board file forwards to
the shared K3 helper. The previous implementation returned 0
unconditionally which matched the first listed configuration
regardless of the actual silicon, which after the dtsi split would
load the wrong tifsstub variant on HS-SE parts.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Use the k3_fit_config_match_security_state() helper introduced in the
earlier "arm: k3: select tifsstub via board_fit_config_name_match"
patch to pick the right tifsstub variant on phycore AM62x and AM62Ax
SoMs at FIT config selection time.
The k3-am625-phycore-som-binman.dtsi and
k3-am62a-phycore-som-binman.dtsi FIT images are split into
per-security-state configurations (conf-hs-se, conf-hs-fs), and
board_fit_config_name_match() in each phycore board file forwards to
the shared K3 helper.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
TI K3 AM62x/AM62Ax/AM62Px boards carry two or three mutually-exclusive
tifsstub variants in their tispl.bin FIT images, all at the same load
address. The existing approach loads every variant and then discards
the wrong ones at runtime via a *p_size = 0 hack in
board_fit_image_post_process(). Switch to selecting the appropriate
FIT configuration up front via board_fit_config_name_match() so only
the correct tifsstub is loaded in the first place.
board_fit_config_name_match() is invoked by the R5 SPL during FIT
config selection. get_device_type() is a simple register read that is
available at that point, so the security state can be determined
early. The matching logic is factored into
k3_fit_config_match_security_state() in arch/arm/mach-k3/common.c so
it can be shared by any K3 board that wants this scheme. It matches
configurations by a suffix appended to the description string:
-hs-se -> HS-SE (K3_DEVICE_TYPE_HS_SE)
-hs-fs -> HS-FS (K3_DEVICE_TYPE_HS_FS)
-gp -> GP (K3_DEVICE_TYPE_GP)
Configurations without a security-state suffix (e.g. u-boot.img) do
not match and fall through to the DTS-specified default config
naturally.
Each TI EVM board defines its board_fit_config_name_match() as a thin
wrapper around the shared helper:
- board/ti/am62x/evm.c (AM625 SK: hs-se, hs-fs, gp)
- board/ti/am62ax/evm.c (AM62A SK: hs-se, hs-fs, gp)
- board/ti/am62px/evm.c (AM62P SK: hs-se, hs-fs, gp)
FIT configurations are split per security state in:
- arch/arm/dts/k3-am625-sk-binman.dtsi
(ti-falcon, ti-spl, ti-spl_unsigned: conf-hs-se/conf-hs-fs/conf-gp)
- arch/arm/dts/k3-am62a-sk-binman.dtsi
(ti-falcon, ti-spl: conf-hs-se/conf-hs-fs; no GP variant on AM62A)
- arch/arm/dts/k3-am62p-sk-binman.dtsi
(ti-falcon, ti-spl: conf-hs-se/conf-hs-fs; no GP variant on AM62P)
The runtime filter in board_fit_image_post_process() is intentionally
left in place. It becomes redundant once every board using the AM62x
family dtsi files migrates to per-state configurations. The dtsi for
phytec phycore and toradex verdin boards is updated by separate
patches in this series, and the now-redundant runtime filter is
removed by the final patch in the series.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Reviewed-by: Anshul Dalal <anshuld@ti.com>
Peng Fan (OSS) <peng.fan@oss.nxp.com> says:
A few misc fixes to dm core. More information could be found in each
commit. Patch list:
dm: core: free old name in device_set_name to prevent leak
dm: core: Correct calloc arguments
dm: core: fix wrong strlen check in of_add_subnode
dm: core: free fdt when fdt_create_empty_tree failure
Link: https://lore.kernel.org/r/20260703-dm-core-v1-0-076d395bded4@nxp.com
If device_set_name is called on a device that already has
DM_FLAG_NAME_ALLOCED set, the old dynamically-allocated name is leaked.
Free it before assigning the new name.
See: drivers/net/mdio_gpio.c:mdio_gpio_bind(). There is
device_set_name() here, however dm_mdio_post_bind() will also call
device_set_name() if "device-name" exists.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Every other calloc in drivers/core uses calloc(count, size) with count
first. Fix the two reversed calloc(sizeof, 1) calls for consistency.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Raphaël Gallais-Pou <raphael.gallais-pou@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The duplicate-name check uses strlen on the search name instead of the
child name, so a child named "trevor" would falsely match a search
for "trev". Fix by checking strlen of child->name.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Raphaël Gallais-Pou <raphael.gallais-pou@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
If fdt_create_empty_tree fails, the malloc-ed fdt buffer is never freed.
Add free before the error return.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Raphaël Gallais-Pou <raphael.gallais-pou@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In warm reset, the value of CTRLMMR_MCU_RST_SRC was not being reset.
This leads to a reset-loop boot failure when a warm reset is triggered
from the MAIN domain (by writing 0x2006 to MCU_RST_CTRL).
Signed-off-by: Anshul Dalal <anshuld@ti.com>
We don't have too many people looking at those at the moment, so having
people getting into the project by adding tests or documentation is I
believe a good thing so let's encourage those specific contributions.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
We are "a bit" struggling with reviewing things and it's most of the
time maintainers or long time contributors reviewing patches on the
mailing list.
Hint that reviewing is also contributing to the project and that even if
you don't feel you're an expert, your review is still welcome and can
help us catch bugs before they are merged.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
This way we don't need to make sure this link still points to something
that exists, as Sphinx will enforce it at build time. It also has the
added benefit that if someone builds the docs they will point at their
docs (though that is debatable whether that's useful, but at least you
stay on the same website).
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
PK, KEK, db, dbx etc must always be measured in PCR7.
DeployedMode and AuditMode should be measured in PCR1 if DeployedMode
is set and PCR7 otherwise.
Fix the u16_strcmp to only change the PCR value for those two variables.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The function defined by the TCG spec looks like:
typedef
EFI_STATUS
(EFIAPI *EFI_TCG2_GET_EVENT_LOG) (
IN EFI_TCG2_PROTOCOL *This,
IN EFI_TCG2_EVENT_LOG_FORMAT EventLogFormat,
OUT EFI_PHYSICAL_ADDRESS *EventLogLocation,
OUT EFI_PHYSICAL_ADDRESS *EventLogLastEntry,
OUT BOOLEAN *EventLogTruncated
);
and the spec mandates that
"If no TPM is present, the function SHALL set the following values and return
EFI_SUCCESS:
EventLogLocation = NULL
EventLogLastEntry = NULL
EventLogTruncated = FALSE"
However, if we set it to NULL the local assignment is discarded when the
function returns. Set it to 0, although on some platforms that's a valid
address.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
When doing a sha256_update() for the measured DT, the size arguments for
fdt_size_dt_struct() and fdt_size_dt_strings() are inversed.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
In efi_sigstore_parse_siglist() sigdata is allocated. But instead of an
allocation matching the size of sigdata, tainted external data was used
to calculate the allocation size. This may lead to buffer overflows.
* Correct the allocation size.
* Follow the man-page. Use the structure size as second argument for
calloc.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Enhance the unit test to verify all Revision fields and all pointers of all
the EFI_BLOCK_IO_PROTOCOL structures.
As the unit test registers its own block io protocol for test purposes,
make sure to initialize its revision properly, as it will be verified as
well.
This can run on the sandbox with the following command:
./u-boot -T -c 'setenv efi_selftest block device; bootefi selftest'
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
In the block device selftest, make the handles pointer global and free it
also in teardown(), to simplify error handling.
We also need to nullify the pointer after freeing it on the normal path,
to avoid freeing it a second time during teardown().
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The list-table layout does not allow grouping columns together,
convert the table into grid-table layout instead and rework it
such that SoC families, generations, architectures and SoCs are
grouped together. Include SoC column to group SoCs together, and
Core column which is useful on SoC like the R-Car X5H where U-Boot
can run on multiple cores in the SoC.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Update the Build section and note that it is only applicable
in case the table above does not contain any board specific
instructions. Include information that the Architecture column
now contains toolchain setup instruction links.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen5 X5H Ironhide board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Retronix R-Car Gen4 V4H Sparrow Hawk board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 D3 Draak board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 E3 Ebisu board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 M3Le Geist board.
Include Renesas R-Car Gen3 SPI NOR installation procedure document.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 H3/M3-W/M3-N ULCB board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 H3/M3-W/M3-N Salvator-X(S) board.
Include generic and HyperFlash Renesas R-Car Gen3 installation
procedure document.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add documents which briefly outline how to set up the SH4/Aarch32/Aarch64
toolchains, for future use in Renesas documentation. Reference all these
documents in the renesas list of boards "Arch" column.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
table_compute_checksum() returns the value that makes the byte sum of
the buffer zero. If the ext_checksum field already contains a non-zero
value (as QEMU's firmware-provided RSDP does), adding that existing
value into the sum produces an incorrect complement. Zero the field
before calling table_compute_checksum() so the calculation starts from
a clean state, matching the pattern used in acpi_write_rsdp().
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Bryan Brattlof <bb@ti.com> says:
Someone figured out that we do not wait long enough for the DDR chip to
be ready during initializing. During that debug it was also discovered
we don't handle warm resets correctly. These 2 patches should fix this.
I don't have a scope fast enough to prove these patches have fixed the
reported issues but I am boot testing (cold and warm resets) with a BBB
at my desk which seems to be OK with these applied.
With how old these platforms are I doubt we will see any issue on our
current devices and probably need a different DDR part to see any
stability improvements but these should help stabilize board wakeups
with different DDR parts.
Link: https://lore.kernel.org/r/20260624-335-ddr-cke-delay-v1-0-21d65d40a83f@ti.com
During a warm reset, the DDR controller will be put into a self refresh
state and will exit self refresh on reset release which will put the
controller in a ready state during bootup.
However we will reinitialize the controller regardless which will
temporarily (~6us) glitch the DDR_RESET line low
Fix this by checking if the VTP controller is already in a ready state
before we initialize the controller unnecessarily.
Fixes: 3ba65f97cb ("am33xx: refactor emif4/ddr to support multiple EMIF instances")
Signed-off-by: Bryan Brattlof <bb@ti.com>
With the Beaglebone Black the delay on DDR_RESET to DDR_CKE is currently
~135us and not the >500us required by JEDEC spec.
The issue here is the REF_CTRL register performs two purposes. It is the
counter for CKE to RESET delay before the DDR controller is initialized
and used to configure the refresh rate after initialization of the
controller.
So to avoid inadvertently configuring the CKE to DDR delay, ensure we
initialize the controller before we configure the refresh rate.
Fixes: 69b918b65d ("am33xx,ddr3: fix ddr3 sdram configuration")
Signed-off-by: Bryan Brattlof <bb@ti.com>
readl_relaxed_poll_timeout() relies on timers. On the beaglebone black,
the timer used by readl_relaxed_poll_timeout() depends on this clock
driver. So we have a sort of circular dependency [enable_clock ->
timer_init -> enable_clock -> timer_init]. It leads to a
division-per-zero during the second timer_init() and the beaglebone
fails to boot with following message:
| CPU : AM335X-GP rev 2.1
| Model: TI AM335x BeagleBone Black
| DRAM: 512 MiB
| ### ERROR ### Please RESET the board ###
Replace readl_relaxed_poll_timeout() with a simple loop that uses CPU
ticks to countdown the timeout. This loop and the value of LDELAY are
inspired from what's done in arch/arm/mach-omap2/am33xx/clock.c
Also, arch/arm/mach-omap2/am33xx/clock.c doesn't return an error on
timeout, it only logs it, so let's stick with it.
Fixes: de2e3f00f2 ("clk: ti: Remove AM33xx dependency")
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Reported-by: Tom Rini <trini@konsulko.com>
Tested-by: Tom Rini <trini@konsulko.com>
Julien Stephan <jstephan@baylibre.com> says:
When I first ran ./tools/qconfig.py, it immediately crashed with a
Python traceback because the configuration database had not yet been
generated.
This series adds a simple pre-check that detects this condition and
prints a clear error message instructing the user to generate the
database first using the -b option, instead of failing with an unhandled
exception.
While looking at the script, I also noticed that the help text still
references the obsolete moveconfig.rst document. This series updates
that reference as well.
Link: https://lore.kernel.org/r/20260702-qconfig-check-for-db-v1-0-f0b96bf8fa44@baylibre.com
This was missed during the renaming of the tool. Fix it.
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Fixes: ea4d6dead3 ("moveconfig: Rename the tool to qconfig")
Reviewed-by: Tom Rini <trini@konsulko.com>
When CONFIG_DATABASE does not exist, read_database() would fail with a
Python traceback. Add a pre-check to print a clear message asking the
user to generate the database first with the -b option.
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Billy Tsai <billy_tsai@aspeedtech.com> says:
The AST2700 is Aspeed's 7th-generation BMC SoC with a dual-die
architecture: SoC0 (CPU die) and SoC1 (I/O die) each have their own SCU
with independent multi-function pin controls. Initial AST2700 platform
support is already merged in next, including the ast2700.dtsi pinctrl0
and pinctrl1 nodes, but no pinctrl driver backs them yet.
This series adds one pinctrl driver per die, each followed by a patch
adding its pin configuration support. Both drivers use the generic
pinctrl framework and are compatible with the Linux kernel device tree
bindings, using the same group and function names as the Linux
aspeed,ast2700-soc0/soc1-pinctrl drivers so pin states can be shared
between the kernel and U-Boot device trees.
Patch 1 adds the SoC0 driver, which models each (function, group) pair
as a flat register mask/value table covering eMMC, VB, VGA DDC, JTAG
master port select, PCIe RC PERST and USB2/USB3 port routing. Patch 2
adds SoC0 pin configuration support: every GPIO18A/GPIO18B ball has
its own IO control register providing a 3 mA to 41 mA drive strength
selector and bias control.
Patch 3 adds the SoC1 driver, porting the per-pin 4-bit multi-function
selector scheme (220 pins, 238 groups, 217 functions) together with
the virtual pins for PCIe RC2 PERST, the USB2 port C/D mode and SGMII
controls. Patch 4 adds SoC1 pin configuration support: a per-pin bias
enable bit and sparse 2-bit drive strength fields (4 mA to 16 mA in
4 mA steps) mirroring the Linux driver layout.
The bias-disable, bias-pull-down, bias-pull-up and drive-strength
properties can be applied per pin or per group. Both drivers implement
gpio_request_enable so the GPIO driver can reclaim pins through the
gpio-ranges already present in ast2700.dtsi, and provide
get_pin_muxing so "pinmux status" reports the active signal of every
pin.
Link: https://lore.kernel.org/r/20260702-pinctrl-v1-0-4d2bd89fc213@aspeedtech.com
The SoC1 SCU provides a bias enable bit per pin in the registers at
0x480 (setting the bit disables the bias; the pull direction is fixed
in silicon) and 2-bit drive strength fields at 0x4C0 selecting 4 mA to
16 mA in 4 mA steps. The pin-to-field mapping of the drive strength
registers is sparse and non-linear, so it is kept in a lookup table
mirroring the Linux driver; pins without an entry reject
drive-strength with -ENOTSUPP.
Support the bias-disable, bias-pull-down, bias-pull-up and
drive-strength properties per pin and per group, and select PINCONF so
the generic pinctrl framework parses them.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
