The loop in lists_bind_fdt uses an indented style for log messages
within the loop and normal messages for errors that lead to the exit of
the function. Due to the change of the previous patch that adds support
for continuation on -ENODEV returned by bind, the log message should be
indented.
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
Currently once a driver matched the compatible string of a device, other
drivers are ignored. If the first matching driver returns -ENODEV, no
other possibly matching drivers are iterated with that compatible of the
device. Instead the next compatible in the list of compatibles is
selected, assuming only one driver matches one compatible at a time.
To be able to use the bind function to return -ENODEV and continue
matching other drivers with the same compatible, move the for loop a bit
to continue the for loop after -ENODEV was returned. The loop had to be
adjusted a bit to still support the 'drv' argument properly. Some
simplifications were done as well.
The modification will only add additional loop iterations if -ENODEV is
returned. Otherwise the exit and continue conditions for the loop stay
the same and do not cause any additional iterations and should not
impact performance.
This is required for ti-musb-host and ti-musb-peripheral which both
match on the same device but differ based on the dr_mode DT property.
Depending on this property, the driver is either UCLASS_USB or
UCLASS_USB_GADGET_GENERIC. By checking the DT property in the bind
function and returning -ENODEV the other driver can probe instead.
Reviewed-by: Simon Glass <simon.glass@canonical.com>
Acked-by: Dinesh Maniyam <dinesh.maniyam@altera.com>
Signed-off-by: Markus Schneider-Pargmann (TI.com) <msp@baylibre.com>
'found' is only used at the end of the function to print a debug
message. No need to maintain a variable if we can just return 0
immediately when a driver was bound successfully.
Reviewed-by: Simon Glass <simon.glass@canonical.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Signed-off-by: Markus Schneider-Pargmann (TI.com) <msp@baylibre.com>
With commit 0535e46d55 ("scripts/dtc: Update to upstream version
v1.7.2-35-g52f07dcca47c") we now require the correct, 8 byte alignment
of a device tree in order to work with it ourselves. This has exposed a
number of issues. In the case of using arch/arm/cpu/u-boot-spl.lds for
an xPL phase and having the BSS be overlayed with the dynamic
relocations sections (here, .rel.dyn) we had missed adding the comment
about our asm memset requirements. Then, when adjusting ALIGN statements
we later missed this one. In turn, when we use objcopy to create our
binary image we end up in the situation where
where the BSS must start out 8 byte aligned as
well as end 8 byte aligned because for appended device tree the
requirement is that the whole BSS (which we add as padding to the
binary) must be 8 byte aligned. Otherwise we end up with the situation
where __bss_end (where we look for the device tree at run time) is
aligned but the size of the BSS we add
Fixes: 7828a1eeb2 ("arm: remove redundant section alignments")
Fixes: 52caad0d14 ("ARM: Align image end to 8 bytes to fit DT alignment")
Reported-by: Fabio Estevam <festevam@gmail.com>
Tested-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Marek Vasut <marek.vasut@mailbox.org>
Some improvements for some boards' DRAM setup, to allow boards with
"odd" DRAM sizes (1.5GB or 3GB), and to support the T113-s4 with double
the co-packaged DRAM. Support for a new board (X96Q TV box), and a fix
for the DT name prefix. Also we support the new AXP318W PMIC, which is
used on new boards with the A733 SoC. There are some preliminary support
patches for this SoC, but they are not quite ready yet - though maybe I
push some uncontroversial ones a bit later still.
The X96Q is a set-top box with an H313 SoC, AXP305 PMIC, 1 or 2 GiB RAM,
8 or 16 GiB eMMC flash, 2x USB A, Micro-SD, HDMI, Ethernet, audio/video
output, and infrared input.
https://x96mini.com/products/x96q-tv-box-android-10-set-top-box
This commit adds a defconfig and some documentation. The devicetree is
already in dts/upstream.
The CONFIG_DRAM_SUNXI_* settings are chosen such that the register
values in the DRAM PHY's MMIO space are as close as possible to those
observed when booting with the preinstalled vendor U-Boot. The DRAM
clock frequency of 600 MHz was reported in the vendor U-Boot's output.
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Add the descriptions for the DC/DC regulators of the AXP318W, and enable
it when CONFIG_AXP318W_POWER is enabled.
Signed-off-by: Yixun Lan <dlan@gentoo.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
The PMIC is also known as AXP819 in vendor pmu code
For DCDC6, 8, 9, the underlying hardware support more than two levels
voltage step tuning, but for now only first two levels are implemented
in this driver, hence highest voltage will be limited at seccond level.
It actual meets board requirement in current design, and we've verified
it in Radxa Cubie A7A board.
Following are detail explanation of voltage tuning stpes for those DCDCs:
DCDC | voltage range | units | steps | implemented
6 | 0.5 - 1.2 | 10 mV | 71 | Y
. | 1.22 - 1.54 | 20 mV | 17 | Y
. | 1.8 - 2.4 | 20 mV | 31 | N
. | 2.44 - 2.76 | 40 mV | 9 | N
--------------------------------------------------
8/9 | 0.5 - 1.2 | 10 mV | 71 | Y
. | 1.22 - 1.84 | 20 mV | 32 | Y
. | 1.9 - 3.4 | 100mV | 16 | N
Signed-off-by: Yixun Lan <dlan@gentoo.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
When CONFIG_OF_UPSTREAM is enabled, the device tree name provided by SPL
already includes the vendor directory (e.g., "allwinner/board-name").
The existing logic in misc_init_r() unconditionally prepends "allwinner/"
for ARM64 builds, resulting in an incorrect path like
"allwinner/allwinner/board-name.dtb".
This patch modifies the logic to only prepend the vendor prefix if
CONFIG_OF_UPSTREAM is NOT enabled. This ensures compatibility with both
legacy builds and the new upstream devicetree structure.
Signed-off-by: Bohdan Chubuk <chbgdn@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Some boards feature an "odd" DRAM size, where the total RAM is 1.5GB or
3GB. Our existing DRAM size detection routines can only detect power-of-2
sized configuration, and on those boards the DRAM size is overestimated,
so this typically breaks the boot quite early.
There doesn't seem to be an easy explicit way to detect those odd-sized
chips, but we can test whether the later part of the memory behaves like
memory, by verifying that a written pattern can be read back.
Experiments show that there is no aliasing effect here, as all locations
in the unimplemented range always return some fixed pattern, and cannot
be changed.
Also so far all those boards use a factor of 3 of some lower power-of-2
number, or 3/4th of some higher number. The size detection routine
discovers the higher number, so we can check for some memory cells beyond
75% of the detected size to be legit.
Add a routine the inverts all bits at a given location in memory, and
reads that back to prove that the new value was stored.
Then test the memory cell at exactly 3/4th of the detected size, and cap
the size of the memory to 75% when this test fails. For good measure
also make sure that memory just below the assumed memory end really
works.
This enables boards which ship with such odd memory sizes.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
The T113-s4 SoC is using the same die as the T113-s3, but comes with
256MiB of co-packaged DRAM. Besides the doubled size, the DRAM chip
seems to be connected slightly differently, which requires to use a
different pin remapping.
Extend the DRAM initialisation code to add support for the T113-S4 aka
T113M4020DC0 by checking the SoC's CHIPID, which is stored in the first
word of the SID efuses.
Signed-off-by: Lukas Schmid <lukas.schmid@netcube.li>
Tested-by: John Watts <contact@jookia.org>
Reviewed-by: John Watts <contact@jookia.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The 9FGV0441 PCIe clock generator can operate in autonomous mode, which
is the default mode. U-Boot currently does not have a driver for this
PCIe clock generator, but Linux 6.17 DT does describe the clock generator
in Sparrow Hawk board DT and this DT is included in U-Boot since commit
eea470fd7f ("Subtree merge tag 'v6.17-dts' of dts repo [1] into dts/upstream").
Reinstate basic PCIe clock description which matches the behavior of
Linux DT before Linux 6.17.y release in in U-Boot DT extras to allow
PCIe to be used on Sparrow Hawk board in U-Boot until the 9FGV0441
driver gets implemented or ported from Linux.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
When aborting a Transfer Descriptor (TD), the xHCI driver updates the
device dequeue pointer by converting the virtual enqueue TRB pointer
into a DMA address.
Previously, the code OR-ed the ring's Dequeue Cycle State (DCS) bit into
the virtual TRB pointer before passing it to xhci_trb_virt_to_dma().
This produced an unaligned virtual address (e.g. ending in 0x...1).
Inside xhci_trb_virt_to_dma(), the offset calculation:
segment_offset = trb - seg->trbs;
operated on this unaligned pointer, resulting in an incorrect TRB index.
In wraparound cases, this caused the bounds check to fail and the
function to return 0.
As a result, a SET_DEQ_PTR command was issued with a DMA address of 0x0,
leading to controller hangs and transfer timeouts, most commonly when
aborting TDs near the end of a ring segment (e.g. index 63).
Fix this by translating the aligned virtual TRB pointer to a DMA address
first, and only then applying the DCS bit to the resulting physical
address.
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
Signed-off-by: ANANDHAKRISHNAN S <anandhakrishnan.s@dicortech.com>
When building with a toolchain that uses a modified sysroot (such as a
Yocto-generated SDK) that does not include libyaml, on a host that does
have libyaml, building dtc will fail with errors like:
HOSTLD scripts/dtc/dtc
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld:
scripts/dtc/yamltree.o: in function `yaml_propval_int':
yamltree.c:(.text+0x167): undefined reference to
`yaml_sequence_start_event_initialize'
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld:
yamltree.c:(.text+0x172): undefined reference to `yaml_emitter_emit'
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld:
yamltree.c:(.text+0x1e8): undefined reference to
`yaml_scalar_event_initialize'
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld:
yamltree.c:(.text+0x1f5): undefined reference to `yaml_emitter_emit'
(... rest of errors truncated ...)
This happens because the test looks for the file in the default path but
uses pkg-config, which is affected by changing sysroot, to determine the
correct linker arguments. This does not happen when building entirely
within yocto, as pseudo will intercept and rewrite the file path when
trying to test for /usr/include/yaml.h to match the sysroot and thus
generate consistent behavior.
This commit adds the PKG_CONFIG_SYSROOT_DIR prefix to the file path
in order to test against the same conditions that are used to resolve
the build flags for libyaml.
In linux commit ef8795f3f1c ("dt-bindings: kbuild: Use DTB files for
validation"), including yaml is disabled again anyway because of other
problems that it causes, so this problem can also be addressed by
partially backporting that commit instead and simply disabling the yaml
support.
Fixes: 0535e46d55 ("scripts/dtc: Update to upstream version v1.7.2-35-g52f07dcca47c")
Signed-off-by: Greg Malysa <malysagreg@gmail.com>
A TrueType font for U-Boot should fulfill the following requirements:
* mono spaced
* support full code page 437
* easily readable
Unfortunately none of the fonts provided with U-Boot fulfills all of these
requirements.
Let's add the DejaVu Mono font. To reduce the code size the characters are
limited to code page 437.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Greg Malysa <malysagreg@gmail.com> says:
This series adds the final pieces to enable mainline U-Boot to build and
boot all Analog Devices SC5xx SoCs and supports the associated carrier
board options. At this point it should be viable for new users for these
platforms to start with the latest version of U-Boot rather than our
vendor fork, however some features (such as OSPI support and falcon
boot) remain unavailable until we are able to unify our implementations
with the mainline implementations.
Link: https://lore.kernel.org/r/20251211080414.5363-1-malysagreg@gmail.com
[trini: Rebuild CI containers to have new tools]
Signed-off-by: Tom Rini <trini@konsulko.com>
This adds missing maintainers entries for the ADI SC5xx defconfigs and
for a device tree binding file that was previously missed.
Signed-off-by: Greg Malysa <malysagreg@gmail.com>
This adds support for the Analog Devices SC598-SOM and configurations
for using it with both the SOMCRR-EZKIT and SOMCRR-EZLITE. This adds
dtsis for both Rev D (including older revisions) and Rev E SOMs, which
are not compatible due to BOM changes. Although no new Rev D SOMs are
produced as of 2025, many are in circulation, so the RevD dtsi is
included to facilitate use for existing customers.
Signed-off-by: Vasileios Bimpikas <vasileios.bimpikas@analog.com>
Signed-off-by: Utsav Agarwal <utsav.agarwal@analog.com>
Signed-off-by: Arturs Artamonovs <arturs.artamonovs@analog.com>
Signed-off-by: Nathan Barrett-Morrison <nathan.morrison@timesys.com>
Signed-off-by: Caleb Ethridge <caleb.ethridge@analog.com>
Signed-off-by: Philip Molloy <philip@philipmolloy.com>
Signed-off-by: Greg Malysa <malysagreg@gmail.com>
The boot ROM on Analog Devices ADSP-SC5xx SoCs requires code packaged
in the LDR format. Normally this is available as part of
our yocto-derived toolchain but, it is not a part of any other pre-made
toolchain anymore, so it is otherwise unavailable in the docker image
for CI. This patch adds a source build from the ADI maintained github
repository. In the future, a package available for install via apt will
be available, but currently there is no arm64 build upstream, so we must
build from source for the time being to support CI on both amd64 and
arm64 runners. The same ldr tool is used for arm and arm64 for all of
our boards with names adjusted to match the expected $(CROSS_COMPILE)
for these boards.
Signed-off-by: Greg Malysa <malysagreg@gmail.com>
Binman is optionally supported for Analog Devices sc5xx SoCs if Yocto is
not being used to create and assemble system images. The spl LDR is
generated locally but other artifacts such as kernel FIT image and root
file system are built externally and must be supplied to binman if used.
Binman is enabled by selecting the SC5XX_USE_BINMAN config symbol and
the image structure is included in the shared sc5xx device tree.
Signed-off-by: Greg Malysa <malysagreg@gmail.com>
Signed-off-by: Utsav Agarwal <utsav.agarwal@analog.com>
Support for the SOM-CRR variants introduces library level changes that
are not modelled in the device tree. As a result they cannot both be
selected at the same time, so this updates the dependency in Kconfig to
prevent them from being enabled together.
Reported-by: Philip Molloy <Philip.Molloy@analog.com>
Signed-off-by: Greg Malysa <malysagreg@gmail.com>
The symbol SC_BOOT_MODE was named incorrectly and inconsistently with
its usage. The selected boot mode is set only by hardware and cannot be
adjusted through software (apart from the use of FORCE_BMODE to instruct
the boot rom to ignore the hardware setting when loading uboot proper,
but this cannot change how SPL is loaded).
This symbol actually controlled the BCODE (easily confused with BMODE,
shorthand for boot mode), so this renames it to SC_BCODE and updates the
help text to reflect its actual usage: the BCODE is an SoC- and boot
mode-specific setting that affects how the boot rom configures QSPI or
OSPI in order to read an LDR file from the associated peripheral.
Reported-by: Philip Molloy <Philip.Molloy@analog.com>
Signed-off-by: Greg Malysa <malysagreg@gmail.com>
Add Kconfig symbols to parameterize the SPI flash layout used in a
default-ish configuration. This adds more flexibility to the default ADI
environment, enabling customers with boards based on but not identical
to an ezkit to reuse more of the infrastructure. Furthermore it allows
for yocto (the expected default) or binman (to be introduced in this
series) to configure or use the flash layout based on a single
definition of all of the parameters when creating an image.
Signed-off-by: Greg Malysa <malysagreg@gmail.com>
Signed-off-by: Utsav Agarwal <utsav.agarwal@analog.com>
In sd_get_capabilities an ACMD is sent (SD_CMD_APP_SEND_SCR),
which requires sending APP_CMD (MMC_CMD_APP_CMD) before.
Currently, the ACMD is retried on error, however APP_CMD isn't.
In this case, when the ACMD fails and it is tried again,
the retry attempts will not be handled as ACMD, which is wrong.
The fix performs the retry attempts on the sequence of
APP_CMD and the ACMD together.
Signed-off-by: Yanir Levin <yanir.levin@tandemg.com>
Reviewed-by: Eran Moshe <emoshe@gsitechnology.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Use dev_read_u32_default() instead of dev_read_u32() to read the
"max-frequency" property from device tree. This preserves the driver-set
cfg->f_max value when the optional "max-frequency" property is not
present, ensuring the controller's default frequency is used as fallback
rather than being overwritten.
Suggested-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
If CONFIG_DM_GPIO is not enabled, compilation fails with the following
errors:
aarch64-none-linux-gnu-ld: drivers/power/regulator/regulator_common.o: in function `regulator_common_of_to_plat':
<...>/u-boot/drivers/power/regulator/regulator_common.c:30: undefined reference to `gpio_request_by_name'
aarch64-none-linux-gnu-ld: drivers/power/regulator/regulator_common.o: in function `regulator_common_get_enable':
<...>/u-boot/drivers/power/regulator/regulator_common.c:57: undefined reference to `dm_gpio_get_value'
aarch64-none-linux-gnu-ld: drivers/power/regulator/regulator_common.o: in function `regulator_common_set_enable':
<...>/u-boot/drivers/power/regulator/regulator_common.c:92: undefined reference to `dm_gpio_set_value'
make: *** [Makefile:2029: u-boot] Error 139
Since the enable gpio is optional we can conditionally skip these calls.
Reviewed-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Replace casting with long to IS_ERR_VALUE() macro to check for error
return values from rate calculation functions. This is the recommended
way to check the return value from clock rate functions.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Replace uclass_get_device_by_ofnode() with syscon_regmap_lookup_by_phandle()
to get the "mediatek,pctl-regmap" syscon device.
Depending on probe order, uclass_get_device_by_ofnode() may fail, but
syscon_regmap_lookup_by_phandle() has logic in it to handle that case
correctly.
The previous implementation could read more than one syscon if the
"mediatek,pctl-regmap" property had more than one phandle, but the one
board with a devicetree that does that is not supported in U-Boot yet,
so we can save that for later (it may never be needed).
Fixes: 424ceba18b ("pinctrl: mediatek: support mediatek,pctl-regmap property")
Signed-off-by: David Lechner <dlechner@baylibre.com>
Pass the unmapped parent ID when setting parent for mux clocks.
For technical reasons, some Mediatek clock driver have a mapping between
the clock IDs used in the devicetree and ID used in the generic clock
framework.
The mtk_clk_mux_set_parent() function is comparing the passed mapped
parent ID against the unmapped IDs in the chip-specific data structures.
Before this change, we were passing the mapped parent ID. When there is
a mapping, this resulted in buggy behavior (usually just incorrectly
failing to find a match and returning an error). We need to pass the
unmapped ID of the parent clock instead for the matching to work
correctly.
Since the reverse lookup is a bit verbose, a helper function is added to
keep the code clean.
Fixes: b135891572 ("clk: mediatek: add of_xlate ops")
Signed-off-by: David Lechner <dlechner@baylibre.com>
Fix typo with correct spelling of "purposes".
Also change "debug" to "debugging" while touching this since that is
the more common phrasing.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Ignore the error return value from mtk_pinconf_bias_set_pupd_r1_r0().
The PUPD/R1/R0 registers only include a small subset of the pins, so
it is normal for this function to return an error for most pins.
Therefore, this error should not be propagated.
This fixes not all pins in a pinmux group being configured in some
cases because the propagated error caused the configuration loop to
exit early.
The rest of the function is refactored to return early on errors to
improve readability.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Set the size of the reg_cals arrays to PINCTRL_PIN_REG_MAX to in all
affected mediatek pinctrl drivers. This is needed to avoid potential
out-of-bounds accesses when they is used in mtk_hw_pin_field_get().
All array members need to be initialized since the code loops from 0
to PINCTRL_PIN_REG_MAX - 1. mt7622_reg_cals was already defined this
way, but the others were not.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Consistently use the device name in debug messages. The clk-uclass file
previously had a mix of printing the dev pointer and the device name.
Changing all to use the device name makes the debug messages more
useful.
Signed-off-by: David Lechner <dlechner@baylibre.com>
