Tom Rini [Wed, 25 Jun 2025 15:57:01 +0000 (09:57 -0600)]
Merge patch series "lmb: use a single API for all allocations"
Sughosh Ganu <sughosh.ganu@linaro.org> says:
The LMB module has a bunch for API's which are used for allocating
memory. There are a couple of API's for requesting memory, and two
more for reserving regions of memory. Replace these different API's
with a single one, lmb_alloc_mem(). The type of allocation to be made
is specified through one of the parameters to the function.
Additionally, the two API's for reserving regions of memory,
lmb_reserve() and lmb_alloc_addr() are the same with one
difference. One can reserve any memory region with lmb_reserve(),
while lmb_alloc_addr() actually checks that the memory region being
requested is part of the LMB memory map. Reserving memory that is not
part of the LMB memory map is pretty futile -- the allocation
functions do not allocate memory which has not been added to the LMB
memory map.
This series also removes the functionality allowing for reserving
memory regions outside the LMB memory map. Any request for reserving a
region of memory outside the LMB memory map now returns an -EINVAL
error.
Certain places in the common code using the LMB API's were not
checking the return value of the functions. Checks have been added for
them. There are some calls being made from the architecture/platform
specific code which too do not check the return value. Those have been
kept the same, as I do not have the platform with me to check if it
causes any issues on those platforms.
In addition, there is a patch which refactors code in
lmb_overlaps_region() and lmb_can_reserve_region() so that both
functionalities can be put in a single function, lmb_overlap_checks().
Finally, a new patch has been added which checks the return value of
the lmb allocation function before copying the device-tree to the
allocated address.
Sughosh Ganu [Tue, 17 Jun 2025 10:43:46 +0000 (16:13 +0530)]
doc: add lmb documentation
The LMB module has undergone significant changes in the recent
past. Add a document which briefly describes what the LMB module does,
and the changes that have been made to it's design since the 2025.01
release.
Sughosh Ganu [Tue, 17 Jun 2025 10:43:45 +0000 (16:13 +0530)]
mach-snapdragon: add a check before copying FDT to fdt_addr_r
The board_late_init() function allocates memory for a bunch of
environment variables, including fdt_addr_r. The device-tree then gets
copied to the memory pointed to by fdt_addr_r. However, the memory
allocation request can fail, in which case the address that is being
written to would not be allocated. Add a check that the memory
allocation has succeeded before copying the device-tree.
Sughosh Ganu [Tue, 17 Jun 2025 10:43:44 +0000 (16:13 +0530)]
lmb: use a single function to check for allocation and reservation requests
The functions that handle allocation requests check if a region of
memory overlaps with a used region. This is done through
lmb_overlaps_region(). Similar checks are done for reservation
requests made to the LMB module, where the caller asks specifically
for a particular region of memory. These checks are being done through
lmb_can_reserve_region().
There are subtle differences in the checking needed for allocation
requests, as against reservation requests. In the former, it is only
needed to be checked if a region is overlapping with an existing
used region, and return as soon as an overlap is found. For
reservation request checks, because U-Boot allows for re-use of in-use
regions with a particular memory attribute, this check has to iterate
through all the regions that might overlap with the requested region,
and then check that the necessary conditions are met to allow for the
overlap.
Combine these two checks in a single function, lmb_overlap_checks() as
both lmb_overlaps_region() and lmb_can_reserve_region() are pretty
similar otherwise.
Sughosh Ganu [Tue, 17 Jun 2025 10:43:41 +0000 (16:13 +0530)]
lmb: replace the lmb_alloc() and lmb_alloc_base() API's
There currently are two API's for requesting memory from the LMB
module, lmb_alloc() and lmb_alloc_base(). The function which does the
actual allocation is the same. Use the earlier introduced API
lmb_alloc_mem() for both types of allocation requests.
Sughosh Ganu [Tue, 17 Jun 2025 10:43:40 +0000 (16:13 +0530)]
lmb: replace lmb_reserve() and lmb_alloc_addr() API's
There currently are multiple allocation API's in the LMB module. There
are a couple of API's for allocating memory(lmb_alloc() and
lmb_alloc_base()), and then there are two for requesting a reservation
for a particular memory region (lmb_reserve() and
lmb_alloc_addr()). Introduce a single API lmb_alloc_mem() which will
cater to all types of allocation requests and replace lmb_reserve()
and lmb_alloc_addr() with the new API.
Moreover, the lmb_reserve() API is pretty similar to the
lmb_alloc_addr() API, with the one difference being that the
lmb_reserve() API allows for reserving any address passed to it --
the address need not be part of the LMB memory map. The
lmb_alloc_addr() does check that the address being requested is
actually part of the LMB memory map.
There is no need to support reserving memory regions which are outside
the LMB memory map. Remove the lmb_reserve() API functionality and use
the functionality provided by lmb_alloc_addr() instead. The
lmb_alloc_addr() will check if the requested address is part of the
LMB memory map and return an error if not.
Tom Rini [Wed, 25 Jun 2025 14:07:16 +0000 (08:07 -0600)]
Merge branch 'next' of https://source.denx.de/u-boot/custodians/u-boot-sunxi into next
This concludes support for the Allwinner A133 SoC, the biggest chunk of
which is the DRAM init code. Also includes support for a devboard using
this SoC, the DT of which got added to the kernel only recently. The
same is true for another H618 devboard, so add the respective devconfig
as well.
Gitlab CI passed, and I booted that briefly on those two boards.
Tom Rini [Tue, 24 Jun 2025 01:51:27 +0000 (19:51 -0600)]
Merge tag 'qcom-next-23Jun-1' of https://source.denx.de/u-boot/custodians/u-boot-snapdragon into next
This PR introduces 3 new platforms, two from the new Dragonwing IQx
series (QCS615 and QCS8300) as well as the IPQ5424.
Additionally:
* Support for booting downstream Android boot images on some phones is
added
* Capsule update support is expanded to be more generic, determining
which partition U-Boot was flashed to automatically and supporting
many more boards.
* Minor capsule update bugs are fixed
* A watchdog driver is added and gets timeout support
* Autoboot now requires pressing "space" specifically to stop booting as
a workaround for some boards getting rogue key presses which would
cause autoboot to fail
* Documentation is added for the Dragonwing boards
* The RB1/2 now use USB gadget mode rather than host
* A bug is fixed where GPIO reads could return incorrect values
We can now correctly identify which partition U-Boot is flashed to
between uefi, xbl, and boot (including A/B support) so enable capsule
update support for all boards.
Calling scsi_scan() results in all the block devices (and EFI block
devices) being destroyed and re-created. This breaks the EFI filesystem
drivers during capsule update.
Remove the call, since boards really should be calling scsi_scan()
themselves during board_init().
mach-snapdragon: CapsuleUpdate: support all boot methods
Expand capsule update support to correctly identify which partition
U-Boot is flashed to (between xbl, uefi, and boot including A/B
variants).
Use qcom_boot_source to determine if we were chainloaded from ABL,
meaning U-Boot is on the boot partition, otherwise we assume uefi if
it's available, finally leaving the xbl partition.
Set a different fw_name based on the target partition to prevent GUID
collisions, since a board may support U-Boot flashed to boot or XBL we
need to differentiate them since the U-Boot binary must be built
differently.
Keep track of whether we were loaded via ABL or if U-Boot is running as
a first-stage bootloader.
For now we set this based on if we have a valid external FDT or not,
since it isn't possible to chainload U-Boot from ABL without there being
an external FDT.
This will be used to inform the capsule update logic which partition
U-Boot is flashed to.
Aswin Murugan [Tue, 10 Jun 2025 09:37:32 +0000 (15:07 +0530)]
board: qualcomm: Add MAINTAINERS entries for Dragonwing platforms
Added MAINTAINERS entries for the Qualcomm Dragonwing platforms, following
the discussion in the referenced thread.
https://lore.kernel.org/u-boot/20250603192206.GK1382132@bill-the-cat/
In order to unzipped kernel from androidboot img, extra memory for
loadaddr is needed. So once fastboot is enabled fastboot memory also
share with loadaddr.
That can balance with memory constrain soc and android usecase.
Some androidboot image have invalid kernel/ramdisk load addr,
force to ignore those value and use loadaddr instead.
There is a concern on exposing the whole memory to image loading is
dangerous. Also, since it's not always possible to change the load
addr by repacking the boot.img (mainly due to AVB signature mismatch),
we need a way to use kernel_addr_r and ramdisk_addr_r.
Casey Connolly [Wed, 4 Jun 2025 11:34:45 +0000 (13:34 +0200)]
board: qualcomm: add a MAINTAINERS file
Add a MAINTAINERS file for assigning maintainership of a particular
Qualcomm platform or board (if board specific files exist). It is
intended to supplement the treewide ARM SNAPDRAGON maintainers with
folks who have a more specific interest.
Add an initial entry for the QCS6490 platform which powers the RB3 Gen 2 board.
Sumit Garg [Fri, 16 May 2025 13:08:54 +0000 (18:38 +0530)]
mach-snapdragon: of_fixup: Drop USB dr_mode override for RB1/2
The default DIP switch configuration on RB1/2 is to enable flashing
support via USB type-c port either using QDL or fastboot. It's just
cumbersome to get the host mode working in U-Boot via DIP switch toggle
when you need the flashing capability using the type-c port.
So instead lets enable fastboot in U-Boot for RB1/2 boards which is
more useful in the default board DIP switch configuration. This let's
us to drop dr_mode DT fixup.
Aswin Murugan [Thu, 8 May 2025 11:36:46 +0000 (17:06 +0530)]
gpio: msm_gpio: return correct value for gpio read
In the current implementation, the GPIO read operation considers
both the input and outbut bits (bits 0 and 1). It should only consider
the state of input bit, i.e bit 0. To address this, mask input bit
alone and read it.
Andre Przywara [Sun, 25 Aug 2024 23:31:42 +0000 (00:31 +0100)]
sunxi: H616: add support for YuzukiHD Chameleon board
The Chameleon board is an OpenHardware devboard made by YuzukiTsuru,
featuring an Allwinner H616 SoC. The form factor resembles the Raspberry
Pi Model A boards, though it differs significantly in its features.
Apart from the usual peripherals of those kind of boards (SD card, eMMC,
WiFi, HDMI), it features four USB-C 2.0 ports.
Add a defconfig for the board, the DRAM parameters have been extracted
from the firmware shipped with the board.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara [Fri, 7 Mar 2025 00:57:12 +0000 (00:57 +0000)]
arm64: dts: allwinner: h616: add YuzukiHD Chameleon support
The Chameleon board is an OpenHardware devboard made by YuzukiTsuru.
The form factor resembles the Raspberry Pi Model A boards, though it
differs significantly in its features:
- Allwinner H618 SoC (4 * Arm Cortex-A53 cores, 1MB L2 cache, 1.4 GHz)
- between 512MiB and 2GiB DDR3 DRAM
- up to 128 GiB eMMC flash
- AXP313a PMIC
- 100 Mbit/s Ethernet pins on a header
- XR829 WIFI+Bluetooth chip
- 4 * USB 2.0 USB-C ports
- microSD card slot
- 3.5mm A/V port
Add the devicetree describing the board's peripherals and their
connections.
Andre Przywara [Mon, 5 May 2025 16:47:29 +0000 (17:47 +0100)]
arm64: dts: allwinner: a100: add Liontron H-A133L board support
The H-A133L board is an industrial development board made by Liontron.
It contains a number of dedicated JST connectors, to connect external
peripherals. It features:
- Allwinner A133 SoC (4 * Arm Cortex-A53 cores at up to 1.6 GHz)
- 1 GiB, 2 GiB or 4 GiB of LPDDR4 DRAM
- between 16 and 128 GiB eMMC flash
- AXP707 PMIC (compatible to AXP803)
- 100 Mbit/s RJ45 Ethernet socket, using an JLSemi JL1101 PHY
- XR829 WIFI+Bluetooth chip
- 2 * USB 2.0 USB-A ports, plus three sets of USB pins on connectors
(connected via a USB hub connected to USB1 on the SoC)
- microSD card slot
- 3.5mm A/V port
- 12V power supply
- connectors for an LVDS or MIPI-DSI panel
Add the devicetree describing the board's peripherals and their
connections.
Despite being a devboard, the manufacturer does not publish a schematic
(I asked), so the PMIC rail assignments were bases on BSP dumps,
educated guesses and some experimentation. Dropping the always-on
property from any of the rails carrying it will make the board hang as
soon as the kernel turns off unused regulators.
Andre Przywara [Wed, 25 Oct 2023 23:37:25 +0000 (00:37 +0100)]
sunxi: add support for the Allwinner A100/A133 SoC
The Allwinner A100 SoC has been around for a while, mostly on cheap
tablets, but didn't generate much interest in the community so far.
There were some efforts by two Allwinner employees in 2020, which led
to basic upstream Linux support for that SoC, although this momentum
dried up pretty quickly, leaving a lot of peripherals unsupported.
The A100 was silently replaced with the seemingly identical Allwinner
A133, which is reportedly a better bin of the A100. So far we assume
that both are compatible from a software perspective. There are some
more devices with the A133 out there now, so people are working on
filling the gaps, and adding U-Boot (and TF-A) support.
Based on the just added pinctrl, clock and DRAM support, this adds the
missing bits, mostly addresses and values for the SPL.
The A133 seems to be an predecessor to the H6, so we can share a lot of
code with that (and the H616 code), and just need to adjust some details.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Cody Eksal [Sat, 12 Oct 2024 06:36:57 +0000 (03:36 -0300)]
sunxi: A133: add DRAM init code
This adds preliminary support for the DRAM controller in the Allwinner
A100/A133 SoCs.
This is work in progress, and has rough edges, but works on at least
three different boards. It contains support for DDR4 and LPDDR4.
Signed-off-by: Cody Eksal <masterr3c0rd@epochal.quest>
[Andre: formatting fixes, adapt to mainline, drop unused parameters,
remove struct struct sunxi_mctl_com_reg, hardcode MR registers,
switch to mctl_check_pattern(), remove simple DRAM check] Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Jerome Forissier [Mon, 23 Jun 2025 19:10:11 +0000 (13:10 -0600)]
arm: kirkwood: fix freeze on boot
Commit 6fe50e395080 ("arm: asm/system.h: mrc and mcr need .arm if
__thumb2__ is not set") is not a proper fix for the LTO link error
mentioned in its description. It causes 32-bit arm instructions to be
mixed with thumb instructions, which the Kirkwood SoCs do not support.
For example, board_init_r() is mostly generated in Thumb-1 mode as
expected since the build flags contain -mthumb -mthumb-interwork. The
MCR instruction corresponding to writefr_extra_feature_reg() is also
correcly emitted as a 32-bit ARM instruction (it cannot be encoded in
Thumb-1 anyways). The problem is, the compiler inlines the MCR without
generating the BX or BLX instruction which are needed to transition
between the ARM and the Thumb-1 states. From the objdump output:
Further investigation is needed to understand how to fix the issue so
that the code size is minimal for all boards. In the mean time, this
fix disables LTO for the two problematic files (common/board_f.c and
common/board_r.c). This makes the Kirkwood-based boards bootable again.
The binary size is increased by 1048 bytes which is perfectly
acceptable.
Fixes: 6fe50e395080 ("arm: asm/system.h: mrc and mcr need .arm if __thumb2__ is not set") Reported-by: Tony Dinh <mibodhi@gmail.com> Tested-by: Tony Dinh <mibodhi@gmail.com> Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org> Signed-off-by: Tom Rini <trini@konsulko.com>
drivers: watchdog: qcom: Add timeout configuration support in watchdog
This patch enhances the Qualcomm watchdog driver by introducing
support for dynamic timeout configuration. Specifically:
- Calculates and sets the bark and bite timeout values based on
the clock rate and the requested timeout in milliseconds.
- Adds retrieval of the watchdog clock rate during probe using
the common clock framework.
- Adds a default timeout value for ARCH_SNAPDRAGON
in WATCHDOG_TIMEOUT_MSECS.
These changes improve the configurability and accuracy of the
watchdog timer on Qualcomm platforms.
This work builds upon the previous submission:
https://lore.kernel.org/all/20250422-b4-qcom-wdt-v3-1-730d4d5a858d@paulsajna.com/
Some Qualcomm device vendors decide to turn the watchdog on in the
bootloader, resulting in the device being reset if it isn't petted every
~30 seconds. Introduce a driver to keep the watchdog happy and prevent this
annoying behaviour.
Signed-off-by: Paul Sajna <hello@paulsajna.com> Co-authored-by: Paul Sajna <hello@paulsajna.com> Tested-by: Paul Sajna <hello@paulsajna.com> Reviewed-by: Stefan Roese <sr@denx.de> Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250422-b4-qcom-wdt-v3-1-730d4d5a858d@paulsajna.com Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
IPQ5424 expects U-Boot to have MBN version 7 header. The qtestsign tool
presently documented doesn't support v7. Hence update the instructions
to use a different tool that can support both v6 and v7.
Tom Rini [Sun, 22 Jun 2025 16:16:43 +0000 (10:16 -0600)]
Merge patch series "rsa and fit_check_sign build fix for v2025.07-rc"
Shiji Yang <yangshiji66@outlook.com> says:
This patchset fixes some compilation errors that I caught in version
v2025.07-rc4 and branch next. If they are acceptable, please apply
them to the master branch. If anyone has a better way to fix these
issues, it's fine to ignore this patchset.
Shiji Yang [Thu, 19 Jun 2025 16:38:18 +0000 (00:38 +0800)]
tools/fit_check_sign: make the module dependent on CONFIG_FIT_SIGNATURE
The function definition of fit_check_sign() is guarded by
"#ifdef CONFIG_FIT_SIGNATURE" in "tools/image-host.c". If we try
to build it without CONFIG_FIT_SIGNATURE, we will get an error:
/usr/bin/ld: tools/fit_check_sign.o: in function `main':
fit_check_sign.c:(.text.startup+0x165): undefined reference to `fit_check_sign'
collect2: error: ld returned 1 exit status
Fixes: 9c79c8fe70da ("tools/fit_check_sign: make key optional") Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Shiji Yang [Thu, 19 Jun 2025 16:38:17 +0000 (00:38 +0800)]
lib: rsa: fix compilation error without openssl
The symbol TOOLS_IMAGE_PRE_LOAD doesn't depend on TOOLS_LIBCRYPTO.
If we choose to build tools without openssl, rsa_verify_openssl()
will attempt to call the unavailable openssl library functions.
Fixes: 942c8c8e6697 ("rsa: Add rsa_verify_openssl() to use openssl for host builds") Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Baruch Siach [Wed, 18 Jun 2025 16:04:35 +0000 (19:04 +0300)]
net: designware: fix bus address dereference
Device bus address might not be valid for direct access when the bus
address and CPU address are not the same. Use dev_bus_to_phys() to
translate bus address back to CPU address.
Fixes: 3d98b8c504e15 ("net: designware: Invalidate RX buffer cache before freeing the DMA descriptor") Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Sam Protsenko [Fri, 20 Jun 2025 18:50:10 +0000 (13:50 -0500)]
board: samsung: e850-96: Load LDFW in board_late_init()
As stated in 5e847f7729b3 ("efi_loader: call efi_init_early() earlier"):
efi_init_early() creates an event hook for block device probing.
It has to be called before any block device is probed.
Indeed, efi_bl_init() registers EVT_DM_POST_PROBE event, which calls
efi_disk_probe() whenever any block device is probed. And to make that
hook work, the initialization of all block devices was put after
efi_init_early() in initcall_run_r():
Because LDFW firmware is being read from MMC, attempt to load LDFW in
board_init() causes MMC driver to be probed. And because board_init() is
executed before efi_init_early(), the hook mentioned above won't work
for MMC devices anymore. So EFI disk objects won't be created, which in
turn makes the EFI subsystem non-functional, showing next symptoms:
- 'efidebug dh' output is empty
- attempt to add boot devices in 'eficonfig' shows this message:
"No block device found!"
- 'bootefi selftest $fdtcontroladdr' shows this warning:
"Cannot persist EFI variables without system partition"
- booting GRUB with 'bootefi' runs minimal GRUB shell which doesn't
see any block devices as well, probably because EFI vars weren't
passed
Load LDFW in board_late_init() instead, as it's called after
efi_init_early(). This fixes the described problem and makes it possible
to run EFI apps like GRUB correctly, add entries in 'eficonfig', and
makes 'efivar --list' command in Linux rootfs actually show EFI
variables.
The only user of LDFW at the moment is the TRNG driver, and it's probed
later, only when it's going to be used (e.g. on "rng" command). So it's
fine to load LDFW in board_late_init(). Now the corresponding call order
will look like this:
Tom Rini [Fri, 20 Jun 2025 18:54:41 +0000 (12:54 -0600)]
Merge patch series "Consistent Kconfig environment options CONFIG_ENV_ prefix"
Marek Vasut <marek.vasut+renesas@mailbox.org> says:
Rename the environment related variables and add ENV_ prefix, so that
all configuration options which are related to environment would have
an CONFIG_ENV_ prefix. No functional change.
Marek Vasut [Mon, 9 Jun 2025 19:26:43 +0000 (21:26 +0200)]
env: Drop DELAY_ENVIRONMENT
There are no users of DELAY_ENVIRONMENT and the same effect can
be achieved either using DT /config/load-environment property,
or by using ENV_IS_NOWHERE . Remove this configuration option
and matching functionality.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Mon, 9 Jun 2025 19:26:42 +0000 (21:26 +0200)]
env: Rename DEFAULT_ENV_FILE to ENV_DEFAULT_ENV_TEXT_FILE
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Also rename USE_DEFAULT_ENV_FILE to USE_ENV_DEFAULT_ENV_TEXT_FILE .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Mon, 9 Jun 2025 19:26:41 +0000 (21:26 +0200)]
env: Rename ENV_MMC_PARTITION to ENV_MMC_SW_PARTITION
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Use ENV_MMC_SW_PARTITION to clarify this is the SD/MMC software
partition table entry selector. Update the help text accordingly.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Mon, 9 Jun 2025 19:26:40 +0000 (21:26 +0200)]
env: Rename SYS_MMC_ENV_PART to ENV_MMC_EMMC_HW_PARTITION
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Use ENV_MMC_EMMC_HW_PARTITION to clarify this is the eMMC hardware
partition selector, not a software partition table entry selector.
Retain the ENV_MMC_ prefix to make it easier to search for all the
SD/MMC related ENV options. Update the help text accordingly.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Mon, 9 Jun 2025 19:26:39 +0000 (21:26 +0200)]
env: Rename SYS_MMC_ENV_DEV to ENV_MMC_DEVICE_INDEX
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Use ENV_MMC_DEVICE_INDEX to clarify this is the SD/MMC device
index, a number, as enumerated by U-Boot. Update the help text
accordingly.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Mon, 9 Jun 2025 19:26:38 +0000 (21:26 +0200)]
env: Rename SYS_RELOC_GD_ENV_ADDR to ENV_RELOC_GD_ENV_ADDR
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Mon, 9 Jun 2025 19:26:37 +0000 (21:26 +0200)]
env: Rename SYS_REDUNDAND_ENVIRONMENT to ENV_REDUNDANT
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Mon, 9 Jun 2025 19:26:36 +0000 (21:26 +0200)]
env: Rename OVERWRITE_ETHADDR_ONCE to ENV_OVERWRITE_ETHADDR_ONCE
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tom Rini [Fri, 20 Jun 2025 14:01:16 +0000 (08:01 -0600)]
Merge patch series "bootstd: Fix efi_mgr usage in bootmeths env var"
Sam Protsenko <semen.protsenko@linaro.org> says:
Defining the 'bootmeths' environment variable with efi_mgr causes NULL
pointer dereference when running 'bootflow scan' on the E850-96 board.
This patch series fixes that, and cleans up the surrounding code a
little while at it.
Sam Protsenko [Sun, 12 Jan 2025 03:42:13 +0000 (21:42 -0600)]
bootstd: Fix incorrect struct name in bootmeth_setup_iter_order()
There is no such thing as struct bootmeth, it's probably a typo. This
issue doesn't affect the execution as it's a pointer, and pointer sizes
are the same for all data types. But it can be confusing, so make it
struct udevice, as it should be.
Fixes: a950d31abe98 ("bootstd: Add the bootmeth uclass and helpers") Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
That happens because in case when 'bootmeths' env var is defined the
bootmeth_efi_mgr driver is not probed, and the memory for its private
data isn't allocated by .priv_auto. In case when 'bootmeths' env var is
not defined, the std->bootmeth_count is 0, and the execution flow in
bootmeth_setup_iter_order() takes "no ordering" path, which in turn runs
uclass_get_device_by_seq() -> ... -> device_probe(), so issue isn't
present there. But when 'bootmeths' is defined and contains efi_mgr, the
std->bootmeth_count > 0, so bootmeth_setup_iter_order() follows the "we
have an ordering" path, where devices are not probed. In other words:
'bootmeths' defined 'bootmeths' not defined
--------------------------------------------------------
priv == NULL priv != NULL
^ ^
| device_alloc_priv()
no probe device_of_to_plat()
^ device_probe()
| uclass_get_device_tail()
dev = order[i] uclass_get_device_by_seq()
^ ^
| have an ordering | no ordering
+----------------+---------------+
|
bootmeth_setup_iter_order()
bootflow_scan_first()
do_bootflow_scan()
Add an explicit device_probe() call in "we have an ordering" case to fix
the issue.
Fixes: c627cfc14c08 ("bootstd: Allow scanning for global bootmeths separately") Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Fri, 20 Jun 2025 13:59:34 +0000 (07:59 -0600)]
Merge tag 'u-boot-at91-2025.10-a' of https://source.denx.de/u-boot/custodians/u-boot-at91 into next
First set of u-boot-at91 features for the 2025.10 cycle:
This feature set includes the addition of new sam9x7 SoC and a new board
named sam9x7-curiosity. There is also new support for sam9x60 compatible
at91 watchdog.
This will allow arch(s) that use device tree blobs to pad the end of the
device tree so they can be modified by board files at run time. This will
help prevent errors such as FDT_ERR_NOSPACE from occurring.
Signed-off-by: Eric Schikschneit <eric.schikschneit@novatechautomation.com>
[trini: Change default order so that X86 && EFI_APP works correctly]
Tom Rini [Thu, 19 Jun 2025 17:00:00 +0000 (11:00 -0600)]
Merge patch series "common/spl fixes"
This series from Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
fixes some regressions related to handling of FIT images with broken
contents that was introduced in this merge window.
There is also a risk of memory leaking within the same portion of code.
The leak will happen if loaded image is bad or damaged. In this case
u-boot-spl will try booting from the other available media. Unfortunately
resources allocated for previous boot media will NOT be freed.
We can't fix that issue as the memory allocation mechanism used here
is unknown. It can be different kinds of malloc() or something else.
To somewhat reduce memory consumption, one can try to reuse previously
allocated memory as it's done in board_spl_fit_buffer_addr() from
test/image/spl_load.c.
The corresponding comment was put to the code as well.
common/spl: handle properly images with bad checksum
load_simple_fit() returns -EPERM for the images with broken signatures.
Unfortunately this may conflict with image loaging selection on the base
of boot phase. See commit 873112db9ce68c38984ff25808dde726f8dd5573
("spl: Support selecting images based on phase in simple FIT").
with damaged "tee" image may finish without errors. This may results in
board bricking.
This patch fixes commit 873112db9ce68c38984ff25808dde726f8dd5573
("spl: Support selecting images based on phase in simple FIT")
by replacing EPERM with EBADSLT places where it should be done.
clk: at91: clk-main: drop parent_name check when registering main_rc oscillator
The clk_register function logs an error if parent_name is missing from the
Device Tree.On the SAM9X7, the main_rc node is omitted to stay aligned with
the Linux Device Tree.Remove the parent_name check in at91_clk_main_rc()
to allow it to pass NULL when the parent is not specified.
Remove clock/at91.h file as it is subset of
dts/upstream/include/dt-bindings/clock/at91.h.
The constants defined in this header are being used only in dts
Zixun LI [Mon, 28 Apr 2025 09:16:26 +0000 (11:16 +0200)]
watchdog: at91sam9_wdt: Add SAM9X60 support
SAM9X60 has a slightly different watchdog implementation:
- Timer value moved into a new register WLR
- Some MR register fields have their position changed
This patch add SAM9X60 support, also adds a compatible
for SAMA5D4 which is the same as existing SAM9260.
Signed-off-by: Zixun LI <admin@hifiphile.com> Reviewed-by: Stefan Roese <sr@denx.de>