| Age | Commit message (Collapse) | Author |
|---|
|
Enable STM_ADC and CM_ADC for stm32mp13_defconfig
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
Add support of STM32 ADCs to STM32MP13x. This patch introduces
stm32_adc_regspec structure, as this is already done in kernel
driver, to manage smartly the differences in register set
between STMP32MP15 and STM32MP13 ADCs.
Signed-off-by: Olivier Moysan <[email protected]>
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
Add "st,stm32mp23-syscfg" compatible.
Fixes: fdd30ee308a2 ("ARM: stm32mp: Add STM32MP23 support")
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
Add txbyteclk to avoid error during clock registration.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
OP-TEE "arm,smc-id" is equal to 0xbc000000 but kernel DT has been
upstream with an incorrect value.
Fix it temporarily until kernel DT is fixed.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
OP-TEE "arm,smc-id" is equal to 0xbc000000 but kernel DT has been
upstream with an incorrect value.
Fix it temporarily until kernel DT is fixed.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
Add U-Boot support for stm32mp257f-dk board.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
All instances of U_BOOT_DRIVER must be unique or we will have link time
failures. It is possible to enable both ufs-renesas-rcar.c and
ufs-renesas-rcar-gen5.c at the same time, so give
ufs-renesas-rcar-gen5.c a new unique U_BOOT_DRIVER name.
Fixes: 3351fe7ecc1a ("ufs: Add UFS driver for Renesas R-Car X5H")
Signed-off-by: Tom Rini <[email protected]>
Acked-by: Marek Vasut <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Sort the Makefile and Kconfig alphabetically again. No functional change.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Igor Belwon <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request efi-2026-01-rc3
CI:
* https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/28355
Documentation:
* Correct the linux/arm64 platform string for Docker builds
* Complete pytest dependencies list with missing packages
UEFI:
* Use Sphinx style comments in efi_selftest_console.c
* Don't include asm/global_data.h in lib/efi_client/efi_app.c twice
* efi_client: correct memset() return value
* Assure fitImage from capsule is used from 8-byte aligned address
* Fix warning when building efi_selftest_snp with clang
|
|
https://source.denx.de/u-boot/custodians/u-boot-i2c
I2C updates for 2026.01-rc3
- i2c: mux: declare staic functions where posible
from Michal
|
|
The fitImage may be stored in EFI update capsule at address that
is not aligned to 8 bytes. Since fitImage is a DT, new version of
libfdt 1.7.2 rejects such an unaligned DT. Patch the code and copy
the fitImage into aligned buffer in case it is not aligned. This
does increase overhead for unaligned fitImages in EFI capsules, but
tries to keep the overhead low for aligned ones.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
When building with clang, we see a warning:
lib/efi_selftest/efi_selftest_snp.c:63:18: error: field dhcp_hdr within
'struct dhcp' is less aligned than 'struct dhcp_hdr' and is usually due
to 'struct dhcp' being packed, which can lead to unaligned accesses
[-Werror,-Wunaligned-access]
when building lib/efi_selftest/efi_selftest_snp.c. Resolve this error by
packing struct dhcp_hdr as well, as the only place it is used also is
packed.
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
The Dockerfile is using linux/arm64 without the /v8 suffix.
Signed-off-by: Bin Meng <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Memset() must return a pointer to the start of the updated memory block.
Fixes: 476476e73b14 ("efi: Add support for loading U-Boot through an EFI stub")
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Remove duplicate #include.
Acked-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
%s/eventfor/event for/
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Convert function comments in efi_selftest_console.c to match
Sphinx style.
Correct function name in print_uuid() comment.
Acked-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Add missing dependencies to the pytest usage documentation and correct
the device tree compiler package name from 'dtc' to 'device-tree-compiler'.
This ensures users have the complete list of dependencies needed to run
the pytest test suite without errors.
Reviewed-by: Mattijs Korpershoek <[email protected]>
Signed-off-by: Kory Maincent (TI.com) <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
i2c_mux_select/deselect() are not called out of i2c-mux-uclass.c that's why
they should be static.
Signed-off-by: Michal Simek <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
- R-Car Gen4 pinctrl alignment with latest reference manual.
|
|
Rev.0.81 of the R-Car V4M Series Hardware User’s Manual removed the
"STPWT_EXTFXR" signal from the pin control register tables. As this is
further unused in the pin control driver, it can be removed safely.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
|
|
Rev.0.71 of the R-Car V4M Series Hardware User’s Manual removed the
"CC5_OSCOUT" signal from the pin control register tables. As this is
further unused in the pin control driver, it can be removed safely.
Signed-off-by: Huy Bui <[email protected]>
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
|
|
Rev.1.30 of the R-Car V4H Series Hardware User’s Manual removed the
"STPWT_EXTFXR" signal from the pin control register tables. As this is
further unused in the pin control driver, it can be removed safely.
Signed-off-by: Huy Bui <[email protected]>
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
|
|
Rev.1.30 of the R-Car V4H Series Hardware User’s Manual removed the
"CC5_OSCOUT" signal from the pin control register tables. As this is
further unused in the pin control driver, it can be removed safely.
Signed-off-by: Huy Bui <[email protected]>
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
|
|
Rev.1.30 of the R-Car V4H Series Hardware User’s Manual removed the
"AVB[01]_MII_*" signals from the pin control register tables. As these
are further unused in the pin control driver, they can be removed
safely.
Signed-off-by: Thanh Quan <[email protected]>
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
|
|
- Remove some legacy code and tighten Kconfig dependencies.
|
|
This driver cannot build when DM_USB_GADGET is enabled as both options
control building of files that use the same global namespace and
functionality. In this case make CI_UDC depend on DM_USB_GADGET being
disabled as non-DM support is the legacy choice.
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
All instances of the U_BOOT_DRIVER must use a unique name or they will
lead to link time failures due to name space conflicts when both are
present. Most of the XHCI drivers follow pattern of xhci_xxx in their
name, but a few used "usb_xhci". Change these to follow the pattern of
the rest of the XHCI glue drivers.
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
|
|
The DWC2 OTG driver depends on an ARM-specific header file to compile,
so make it depend on ARM.
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
The last of the users of the legacy musb drivers have been
migrated so now remove the old musb stack, all users should
now be using the new musb stack if they need this functionality.
Signed-off-by: Peter Robinson <[email protected]>
[trini: Remove a Makefile reference that was missed in v1]
Signed-off-by: Tom Rini <[email protected]>
|
|
The USB_OMAP3 driver was (re)added in commit e74e9f620a6 as part
of migrating to DM_USB but the config already had MUSB_OMAP2PLUS
which is the newer musb driver and what other omap3 devices use.
So drop it so we can drop the old driver.
Signed-off-by: Peter Robinson <[email protected]>
|
|
It makes no sense to ask about nor enable SPL_USB_GADGET without
SPL_FRAMEWORK being enabled. Attempting to do so leads to Kconfig noting
dependency issues. Add the missing dependency.
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
Anshul Dalal <[email protected]> says:
TI offers SoCs in various speed grades, each speed grade specifies a
certain maximum operating frequency of the clocks for each core.
In K3's boot flow, the R5 SPL starts the A53 or A72 core and configures
the correct clocks and power using the K3 ARM64 rproc driver
(compatible: ti,am654-rproc). However, the driver expects the dt node
for the ARM64 core to be set with a correct "assigned-clock-rates"
value.
Currently the dt has a value of 1.2GHz for the A53 core on AM62a, this
is incorrect for lower speed grades. Therefore this patch set adds
support for fixing this value at runtime based on the detected speed
grade from the efuse MMR.
For the speed grade table, refer to Table 6-1 of the AM62a datasheet.
Link: https://www.ti.com/lit/ds/symlink/am62a7.pdf
Link: https://lore.kernel.org/r/[email protected]
|
|
Speed grades indicate the maximum operating frequency of any core on the
SoC. This patch adds support for the same to AM62a, this allows the A53
core to be started with the correct frequency by the R5 SPL.
Reference:
Device Speed Grades (Table 6-1) in AM62a7 Datasheet
https://www.ti.com/lit/ds/symlink/am62a7.pdf (Page#82)
Signed-off-by: Anshul Dalal <[email protected]>
|
|
The K3 ARM64 rproc driver uses the "assigned-clock-rates" value in the
respective "/a53@0" node to properly configure the clocks for the A53
core.
Although the clock value in the DT node might need to be fixed based on
SoC's speed grade at runtime. Certain SoCs such as AM62p and AM62x
already had this implemented, this patch moves the common code to
common.c to avoid duplication and simplify speed grade handling.
The logic to detect the correct entry in the "assigned-clock-rates"
property has also changed. Where we earlier relied on per SoC specific
device and clock IDs for the A53 core, we now use the "clock-names"
property which is device agnostic.
Signed-off-by: Anshul Dalal <[email protected]>
Reviewed-by: Aniket Limaye <[email protected]>
|
|
fdt_fixup_cpu_freq_nodes_am62p is used to delete unsupported opp table
entries at runtime based on the SoC's speed grade.
However, the ti-cpufreq driver in kernel already has support for
rejecting unsupported entries. Therefore this fdt fixup is not necessary
and can be dropped.
Fixes: 8d05cbef73ae ("arm: mach-k3: am62p: Fixup a53 max cpu frequency by speed-grade")
Signed-off-by: Anshul Dalal <[email protected]>
|
|
Add the compatible string of Exynos7's PMU as defined in upstream
dt-schema. This also supports derivative PMUs as defined in schema.
There's no additional setup required here, so pmu_init is skipped.
Signed-off-by: Kaustabh Chakraborty <[email protected]>
Signed-off-by: Minkyu Kang <[email protected]>
|
|
Add the compatible for Exynos8895 UART as described in upstream
devicetree bindings. This enables support for Exynos8895 and other
similar UART devices, such as Exynos7870. Other than that, the driver
works as-is.
Signed-off-by: Kaustabh Chakraborty <[email protected]>
Reviewed-by: Henrik Grimler <[email protected]>
Signed-off-by: Minkyu Kang <[email protected]>
|
|
The pinctrl blocks for Exynos7870 and Exynos7880 are similar, however in
Exynos7870, the CCORE block is actually referred to as MIF. Since
ordering happens lexically, it isn't directly compatible with
samsung,exynos78x0-pinctrl.
Signed-off-by: Kaustabh Chakraborty <[email protected]>
Signed-off-by: Minkyu Kang <[email protected]>
|
|
The devicetree of Samsung devices typically have the pin controller and
GPIO bank descriptors under the same pinctrl node. In U-Boot, these are
handled by two separate drivers. It is not possible to invoke both
drivers from a single node compatible.
Bind the GPIO driver on pinctrl driver bind, with the same OF node as
the pinctrl driver. This solution is already being used in other pinctrl
drivers. The hierarchy, as represented in `dm tree`, is as follows:
pinctrl@13750000
|-- gpio-banks
| |-- gpr0-gpio-bank
| |-- gpr1-gpio-bank
| |-- gpr2-gpio-bank
| |-- gpr3-gpio-bank
| `-- gpr4-gpio-bank
|-- sd0-bus-width1-pins
|-- sd0-bus-width4-pins
|-- sd0-bus-width8-pins
`-- sd0-clk-pins
Since a bind function doesn't exist, create and add it to all pinctrl
drivers.
Signed-off-by: Kaustabh Chakraborty <[email protected]>
Signed-off-by: Minkyu Kang <[email protected]>
|
|
There may be cases where the flags set for a clock is not available.
This is usually the case with clocks which have been retrieved using
clk_request(). However, clock flags are found in their respective
private clock struct, so use that instead.
Signed-off-by: Kaustabh Chakraborty <[email protected]>
Signed-off-by: Minkyu Kang <[email protected]>
|
|
Introduce a simple clock driver for Exynos7870's CMU blocks, more
specifically, CMU_MIF, CMU_FSYS, and CMU_PERI banks. This should be
enough to serve U-Boot's minimal requirements.
Signed-off-by: Kaustabh Chakraborty <[email protected]>
Signed-off-by: Minkyu Kang <[email protected]>
|
|
The request function performs a simple check if the clock with the
provided ID is present or not. This is done with a simple call to
clk_get_by_id(). A non-zero return value indicates that the requested
clock is not available.
In some cases, clk->dev points to the clock bank device instead of
the clock device. This pointer is therefore overwritten in order to
reference to the correct device instance.
Signed-off-by: Kaustabh Chakraborty <[email protected]>
Signed-off-by: Minkyu Kang <[email protected]>
|
|
PLL1417X seem to be compatible with PLL0822X, as also seen in the
respective Linux kernel driver. Add an enum entry for the type, while
merely being an alias for PLL0822X.
Signed-off-by: Kaustabh Chakraborty <[email protected]>
Signed-off-by: Minkyu Kang <[email protected]>
|
|
Add register functions for fixed rate and fixed factor clock drivers.
The vendor-specific structs defined are borrowed from the CCF driver
found in the Linux kernel.
Signed-off-by: Kaustabh Chakraborty <[email protected]>
Signed-off-by: Minkyu Kang <[email protected]>
|
|
The device pointer set as NULL causes problems when clock banks depend
on clocks from another clock bank. In such case, the appropriate clock
needs to be resolved from OF phandle arguments, which is not possible if
the associated device is not provided. Make necessary changes to make
the correct device pointer available.
Signed-off-by: Kaustabh Chakraborty <[email protected]>
Signed-off-by: Minkyu Kang <[email protected]>
|
|
lookup"
Rasmus Villemoes <[email protected]> says:
Hopefully third time's the charm.
I merely wanted to add support (mostly for use by the 'gpio' shell
command) for looking up a gpio via the gpio-line-names DT property. We
already have a "gpio_request_by_line_name()", but cmd/gpio.c does a
separate "lookup + request", so it felt more natural to teach the
lookup machinery this as well. That ran into
OF_CONTROL-but-not-OF_LIBFDT being a thing for SPL, so here's yet
another attempt.
Now, when trying to do my civic duty and add tests for this, I found
that test/dm/gpio.c has been defunct for a couple of years, and
reinstating it is not entirely trivial.
After a couple of rounds CI is now happy with this:
https://github.com/u-boot/u-boot/pull/828
Link: https://lore.kernel.org/r/[email protected]
|
|
Signed-off-by: Rasmus Villemoes <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
In scripts as well as interactively, it's much nicer to be able to
refer to GPIOs via their names defined in the device tree property
"gpio-line-names", instead of the rather opaque names derived from the
bank name with a _xx suffix. E.g.
gpio read factory_reset FACTORY_RESET
if test $factory_reset = 1 ; then ...
versus
gpio read factory_reset gpio@481ac000_16
if test $factory_reset = 1 ; then ...
This is also consistent with the move on the linux/userspace side towards
using line names instead of legacy chip+offset or the even more legacy
global gpio numbering in sysfs.
As dev_read_stringlist_search() depends on both OF_CONTROL and
OF_LIBFDT (which matters for the SPL case), we need some .config
conditional. However, it only adds about ~50 bytes of code to U-Boot
proper, and dm_gpio_lookup_name() most often ends up being GC'ed for
SPL, thus adds no overhead there, so for now make it a hidden symbol
which is merely a convenient shorthand for
CONFIG_IS_ENABLED(OF_CONTROL) && CONFIG_IS_ENABLED(OF_LIBFDT).
Signed-off-by: Rasmus Villemoes <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
