| Age | Commit message (Collapse) | Author |
|---|
|
Enable OF_SYSTEM_SETUP for AM62D2 to ensure FDT fixups are applied to
the dtb before passing to kernel.
Signed-off-by: Paresh Bhagat <[email protected]>
Reviewed-by: Anshul Dalal <[email protected]>
|
|
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: 8b0fc29de0e3 ("arm: mach-k3: am62: Fixup TF-A/OP-TEE reserved-memory node in FDT")
Signed-off-by: Paresh Bhagat <[email protected]>
Reviewed-by: Neha Malcom Francis <[email protected]>
Acked-by: Andrew Davis <[email protected]>
|
|
FIT configurations"
Aristo Chen <[email protected]> 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/[email protected]/
[2] https://github.com/open-source-firmware/flat-image-tree/issues/32
[3] https://lore.kernel.org/u-boot/[email protected]/
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Reviewed-by: Anshul Dalal <[email protected]>
Signed-off-by: Aristo Chen <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Anshul Dalal <[email protected]>
|
|
Peng Fan (OSS) <[email protected]> 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/[email protected]
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Raphaël Gallais-Pou <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Raphaël Gallais-Pou <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Raphaël Gallais-Pou <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-efi
Pull request efi-2026-10-rc1
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-efi/-/pipelines/648
Documentation:
* board: renesas: Document SH/Aarch32/Aarch64 toolchain setup
* board: renesas: Document Aarch32 toolchain setup in RZ/N1
* board: renesas: Document Renesas R-Car Gen3 H3/M3-W/M3-N Salvator-X(S) board
* board: renesas: Document Renesas R-Car Gen3 H3/M3-W/M3-N ULCB board
* board: renesas: Document Renesas R-Car Gen3 M3Le Geist board
* board: renesas: Document Renesas R-Car Gen3 E3 Ebisu board
* board: renesas: Document Renesas R-Car Gen3 D3 Draak board
* board: renesas: Document Retronix R-Car Gen4 V4H Sparrow Hawk board
* board: renesas: Document Renesas R-Car Gen5 X5H Ironhide board
* board: renesas: Update Renesas generic build section
* board: renesas: Convert Renesas board support table to grid table
* boards: amlogic: update documentation for Beelink GT1 Ultimate
* CONTRIBUTE: use internal link instead of hardcoded external URL
* CONTRIBUTE: tell people reviewing *is* contributing
* CONTRIBUTE: explicitly list tests and documentation as welcome contributions
UEFI:
* fix building with CONFIG_EFI_VARIABLES_PRESEED=y
* fix buffer overrun in efi_sigstore_parse_siglist
* Correctly count the size on DTB measurements
* Change the return values if a TPM is missing during GetEventLog
* Measure secure boot variables in the correct PCR if DeployedMode is set
* fix missing EFI_EXIT in efi_disconnect_controller
* efi_selftest: free handles on teardown()
* efi_selftest: test block io revision and pointers
Others:
* qfw: fix RSDP ACPI table ext_checksum computation
|
|
contributions
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
is set
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 <[email protected]>
Acked-by: Heinrich Schuchardt <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
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 <[email protected]>
Acked-by: Heinrich Schuchardt <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
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é <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Since commit bd3f9ee679b4 ("kbuild: Bump the build system to 6.1")
out-of-tree builds with CONFIG_EFI_VARIABLES_PRESEED=y fail with errors
like:
../lib/efi_loader/efi_var_seed.S:14: Error: file not found:
ubootefi.var
For out-of-tree build we cannot use CONFIG_EFI_VAR_SEED_FILE in the
.incbin statement of file efi_var_seed.S.
* We have to prepend $(srctree) if the path is relative.
* We must not prepend $(srctree) if the path is absolute.
Fixes: bd3f9ee679b4 ("kbuild: Bump the build system to 6.1")
Reported-by: Jon Mason <[email protected]>
Closes: https://lore.kernel.org/u-boot/CAPoiz9zg4OXgHo5J3WtJHKOEuWOdCDrugWfAt6Z+d71j=+q8oA@mail.gmail.com/T/#mffaca10a9e812d03eceafad59999a02e57258b9a
Tested-by: Nora Schiffer <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen5 X5H Ironhide board.
Signed-off-by: Marek Vasut <[email protected]>
|
|
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 <[email protected]>
|
|
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 D3 Draak board.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 E3 Ebisu board.
Signed-off-by: Marek Vasut <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
board
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 <[email protected]>
|
|
Reference Aarch64 toolchain setup in RZ/N1 documentation.
Signed-off-by: Marek Vasut <[email protected]>
|
|
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 <[email protected]>
|
|
We are missing a call to EFI_EXIT() when returning from
efi_disconnect_controller(), which we need after having called EFI_ENTRY().
Fix this by jumping to the common error path, which does call EFI_EXIT().
Even though the common error path may try to free child_handle_buffer, this
cannot harm in our case as it always NULL.
This is inspired by a barebox fix. [1]
Link: https://git.pengutronix.de/cgit/barebox/commit/?id=080db65e39a877b000baaf843c997a69821dfe69 [1]
Fixes: 314bed6c854e ("efi_loader: fix DisconnectController() for sole child")
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
fix formatting
Signed-off-by: Karl Chan <[email protected]>
The patch replaces Unicode NO-BREAK-SPACE U+00A2 by SPACE U+0020.
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Bryan Brattlof <[email protected]> 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/[email protected]
|
|
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: 3ba65f97cbed ("am33xx: refactor emif4/ddr to support multiple EMIF instances")
Signed-off-by: Bryan Brattlof <[email protected]>
|
|
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: 69b918b65d11 ("am33xx,ddr3: fix ddr3 sdram configuration")
Signed-off-by: Bryan Brattlof <[email protected]>
|
|
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: de2e3f00f2fa ("clk: ti: Remove AM33xx dependency")
Signed-off-by: Bastien Curutchet <[email protected]>
Reported-by: Tom Rini <[email protected]>
Tested-by: Tom Rini <[email protected]>
|
|
missing"
Julien Stephan <[email protected]> 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/[email protected]
|
|
This was missed during the renaming of the tool. Fix it.
Signed-off-by: Julien Stephan <[email protected]>
Fixes: ea4d6dead372 ("moveconfig: Rename the tool to qconfig")
Reviewed-by: Tom Rini <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Billy Tsai <[email protected]> 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/[email protected]
|
|
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 <[email protected]>
|
|
Add the pinctrl driver for the AST2700 SoC1 (I/O) die.
Unlike previous Aspeed generations, the SoC1 SCU assigns every pin a
4-bit multi-function selector field in a contiguous register range
starting at SCU 0x400, eight pins per register. Only bits [2:0] of
each field select the function; bit 3 is reserved read-only and must
not be written. The driver therefore keeps per-pin group tables and
per-function mux values, mirroring the Linux
aspeed,ast2700-soc1-pinctrl driver, and shares the same device tree
bindings: 220 pins, 238 groups and 217 functions with identical names,
so pin states written for the Linux driver work unmodified.
A few controls live outside the pin-indexed range and are handled as
virtual pins: PCIERC2_PERST (SCU 0x908), the USB2 port C/D mode fields
(SCU 0x3B0) and SGMII0 (SCU 0x47C).
The gpio_request_enable hook restores a pin to GPIO by writing mux
value 0, except for the ADC-capable balls W17..AB19 where function 1
selects GPIO and 0 selects the ADC input.
Signed-off-by: Billy Tsai <[email protected]>
|
|
Each GPIO18A/GPIO18B ball has its own IO control register starting at
SCU 0x480, providing a 4-bit drive strength selector (3 mA to 41 mA in
hardware-defined steps), a bias enable bit and a pull direction bit.
Extend the group table with the pin members of the ball-backed groups
so bias-disable, bias-pull-down, bias-pull-up and drive-strength
properties can be applied per group as well as per pin. The routing
groups (USB, JTAG, PCIe RC) have no package balls and reject pin
configuration with -ENOTSUPP.
Select PINCONF so the generic pinctrl framework parses the pin
configuration properties.
Signed-off-by: Billy Tsai <[email protected]>
|
|
The AST2700 is a dual-die BMC SoC: SoC0 (CPU die) and SoC1 (I/O die)
each have their own SCU with independent multi-function pin controls.
Add the pinctrl driver for the SoC0 die. The driver uses the generic
pinctrl framework and is compatible with the Linux kernel device tree
bindings, i.e. pin states are described with the same "function" and
"groups" properties and the same names as the Linux
aspeed,ast2700-soc0-pinctrl driver.
Unlike the older AST2500/AST2600 SCUs where each signal is enabled by
independent bits, the SoC0 mux selections mix single-bit enables
(eMMC, VGA DDC, VB strap), multi-bit selector fields (JTAG master port
select, USB2/USB3 port routing) and reset-control bits (PCIe RC
PERST). Model each (function, group) pair as one register
mask/value write so all of them fit a single flat table.
The gpio_request_enable hook releases the GPIO18A/GPIO18B pins to GPIO
mode by clearing every signal enable bit that claims the pin, matching
the Linux driver behaviour.
Signed-off-by: Billy Tsai <[email protected]>
|
