There's been a surprising amount of activity lately on the Qualcomm
side with the two oldest boards getting some fresh attention and a lot
of cleanup and polish going on across the board.
* SDM660 gets USB phy fixes and a pinctrl driver
* The recently added SA8775P/QCS9100 SoC gets a pinctrl driver
* The Qualcomm pinctrl driver now handles reserved pins correctly,
fixing crashes on some boards when running "gpio status -a"
* OF_UPSTREAM_BUILD_VENDOR is enabled in qcom_defconfig
* SDM845 and SC7280 get missing clocks added (since we're now stricter
about those). This gets USB working more reliably in more cases.
* DM_USB_GADGET is enabled for all boards using DWC3 and fasbtoot is
enabled too
* A bug in the livetree fixup code is fixed (making USB work on a lot
more platforms)
* Button label lookup is made case insensitive* bootretry becomes more dynamic, allowing it to be hijacked to make a
"persistent" boot menu that allows dropping to U-Boot shell later on
* A new qcom-phone.config fragment is added along with a phone-specific
default environment and phone-specific debugging/bringup docs. These
make U-Boot more usable on devices without a serial port or keyboard.
* The db820c gets fixed up and updated documentation
* The db410c also gets some love and modernisation as well as a new
reviewer.
* A new driver is added for the USB VBUS regulator found on various
Qualcomm PMICs
* The Qualcomm SPMI driver gets some fixes and cleanup for SPMI v5 and
v7 support.
* Add support for loading FIT images including initrd
- efi_loader: efi_load_initrd: provide a memory mapped initrd
- efi_loader: binary_run: register an initrd
- bootm: add support for initrd in do_bootm_efi
* efi_selftest: remove un-needed NULL checks
* efi: Fix efiboot for payloads loaded from memory
* Print extra information from the bootmgr
* Move public cert for capsules to .rodata
* Set EFI capsule dfu_alt_info env explicitly
* Make FDT extra space configurable
* Install the ACPI table from the bloblist
* Handle GD_FLG_SKIP_RELOC
* Handle malloc() errors
Others:
* acpi: select CONFIG_BLOBLIST
* smbios: select CONFIG_BLOBLIST
* xilinx: dfu: Fill directly update_info.dfu_string
* cmd: fwu: Dump custom fields from mdata structure
* board: remove capsule update support in set_dfu_alt_info()
Stephan Gerhold [Mon, 7 Apr 2025 16:59:34 +0000 (18:59 +0200)]
board: dragonboard410c: Update maintainers
Ramon has been inactive on the U-Boot mailing list for over a year now and
the DB410c port has not been updated much lately. I've been doing most of
the DB410c-specific fixes/rework lately and try to test it every now and
then, so add myself as new maintainer. Also add Sam as reviewer, since he's
been doing lots of testing and reviews for MSM8916 recently.
Cc: Sam Day <me@samcday.com> Cc: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Link: https://lore.kernel.org/r/20250407-db410c-fixes-v1-13-524aefbc8bb4@linaro.org Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Stephan Gerhold [Mon, 7 Apr 2025 16:59:33 +0000 (18:59 +0200)]
board: dragonboard410c: Use button_cmd instead of custom code
Simplify the board code by using the new BUTTON_CMD functionality, instead
of implementing this separately using C code. This allows disabling or
customizing this functionality if wanted.
Stephan Gerhold [Mon, 7 Apr 2025 16:59:32 +0000 (18:59 +0200)]
board: dragonboard410c: Enable support for Android boot images
The U-Boot port for DB410c still has plenty of extra space available at
this point, so avoid disabling features that would be normally enabled by
default. In particular, this incldues support for Android boot images,
which is quite likely to be used together with the USB Fastboot interface.
Stephan Gerhold [Mon, 7 Apr 2025 16:59:31 +0000 (18:59 +0200)]
board: dragonboard410c: Use BOOTSTD instead of DISTRO_DEFAULTS
Reduce the environment size by using standard boot instead of distro boot.
It uses faster bootdevs first by default (eMMC -> SD -> USB -> Network), so
set "boot_targets" to keep the current ordering (USB -> SD -> eMMC ->
Network). Perhaps this should be changed for consistency, but for now this
keeps the behavior similar to before.
Stephan Gerhold [Mon, 7 Apr 2025 16:59:30 +0000 (18:59 +0200)]
board: dragonboard410c: Enable RTL8152 ethernet
The Geniatech DB4 V3 [1] has a RTL8152 onboard for Ethernet. I don't have
one to test if that works, but the other USB Ethernet drivers work pretty
much as-is, so just enable it with the assumption it will work out fine.
Stephan Gerhold [Mon, 7 Apr 2025 16:59:29 +0000 (18:59 +0200)]
board: dragonboard410c: Fix counter frequency
The actual counter frequency is 19.2 MHz, not 19.0 MHz. This isn't really
used so far though, since probably no one (except me) ever tried using
U-Boot in EL3 where we need to program the counter frequency.
Stephan Gerhold [Mon, 7 Apr 2025 16:59:28 +0000 (18:59 +0200)]
board: dragonboard410c: Use dynamically allocated load addresses
The generic Qualcomm board code allocates addresses for loading the kernel,
ramdisk, DT, fastboot etc. This also happens on the DB410c and already
overrides these definitions defined in the default env. So let's just drop
the static ones, since the dynamic ones work just fine.
Stephan Gerhold [Mon, 7 Apr 2025 16:59:26 +0000 (18:59 +0200)]
board: dragonboard410c: Drop reflash functionality
This is broken ever since we switched to using U-Boot as first stage
bootloader. Since no one seems to test this actively, let's just drop this
entirely. There are other tools available for re-flashing the DB410c.
Stephan Gerhold [Mon, 7 Apr 2025 16:59:25 +0000 (18:59 +0200)]
board: dragonboard410c: Drop UNSTUFF_BITS() macro
This was originally taken from Linux, but at this point it's an inline
function upstream and no longer a macro. Given that we just want to extract
the serial number from the MMC CID, let's just inline that specifically.
This is also the style used in the MMC core code within U-Boot.
Stephan Gerhold [Mon, 7 Apr 2025 16:59:24 +0000 (18:59 +0200)]
board: dragonboard410c: Fix BD address
local-bd-address in the device tree needs to be formatted with the least
significant byte first (i.e. little endian). We're not doing this when
adding it to the DT, which means the MAC address ends up being reversed in
Linux. Fix this by reversing the array before setting it in the DT.
We're also flipping the wrong bit when generating the BD address. Before
reversing the array, the least significant bit is in the last byte.
Fixes: ff06dc240325 ("db410: alter WLAN/BT MAC address fixup") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Link: https://lore.kernel.org/r/20250407-db410c-fixes-v1-3-524aefbc8bb4@linaro.org Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Stephan Gerhold [Mon, 7 Apr 2025 16:59:23 +0000 (18:59 +0200)]
board: dragonboard410c: Fix RAM size
DB410c has exactly 1 GiB of RAM. Some of it is reserved, but this is
described separately in the DT.
This was fixed before in commit 1d667227ea51 ("board: dragonboard410c: Fix
PHYS_SDRAM_1_SIZE"), but was reintroduced when DB410c was converted to use
the upstream device tree.
Note that there are variants of apq8016-sbc with 2 GiB RAM (e.g. the
Geniatech DB4). They need the WIP SMEM memory map parsing [1] to use the
full amount of RAM.
Stephan Gerhold [Mon, 7 Apr 2025 16:59:22 +0000 (18:59 +0200)]
mach-snapdragon: Fix EL2 boot on DragonBoard 410c
The workaround for the "PSCI bug" on DragonBoard 410c implemented in
arch/arm/mach-snapdragon/include/mach/boot0.h clobbers the x0 register
by storing the CurrentEL in there. When running in EL1, the mode switch
sequence implemented there later clears the register again, but this is
skipped when U-Boot is booted in EL2.
This causes crashes in the mach-snapdragon board_fdt_blob_setup() later,
because the invalid address stored in x0 gets dereferenced to check if it
points to a valid DTB.
We can't rely on having a valid values in the CPU registers for the first
stage bootloader configuration on DB410c, and nothing would place a DTB
there anyway. Skip selecting the SAVE_PREV_BL_FDT_ADDR option for the boot0
hook case to avoid crashing with the clobbered register value.
Some Qualcomm boards feature reserved ranges of pins which are protected
by firmware. Attempting to read or write any registers associated with
these pins results the board resetting.
Add support for parsing these ranges from devicetree and ensure that the
pinctrl and GPIO drivers don't try to interact with these pins.
Caleb Connolly [Mon, 31 Mar 2025 12:23:21 +0000 (14:23 +0200)]
doc: board/qualcomm: describe phone support and bringup
Add some documentation which attempts to describe Qualcomm smartphone
support with the qcom-phone.config fragment, as well as a high level
debugging guide for diagnosing U-Boot issues when UART and framebuffer
are unavailable.
Caleb Connolly [Mon, 31 Mar 2025 12:23:20 +0000 (14:23 +0200)]
bootretry: check for bootretry variable changes
To enable more complex sequencing of the bootmenu, autoboot, and
bootretry, handle changes to the bootretry variable between tries. This
makes it possible to turn bootretry off (e.g. to drop to a shell) and
then back on again.
This makes it possible to have a persistent bootmenu (the only way to
navigate U-Boot on devices like smartphones which lack a physical
keyboard) by having bootcmd be defined to launch the bootmenu. This
allows for menu options like enabling USB mass storage gadget to return
back to the boot menu once the gadget is shut down.
Caleb Connolly [Mon, 31 Mar 2025 12:23:18 +0000 (14:23 +0200)]
board/qualcomm: introduce phone config
Phones don't have keyboards! Introduce a phone-specific config fragment
and associated environment file to make U-Boot more useful on these
devices. This allows for navigating via the buttons and enabling
various USB gadget modes or displaying info about U-Boot.
Neil Armstrong [Tue, 1 Apr 2025 07:45:19 +0000 (09:45 +0200)]
gpio: msm: fix get_function return for special pins
The get_function callback wrongly returns 0 for special pins,
return the appropriate pin function by probing into the special
pins data fields to find if the pin is gpio capable.
Martin Schwan [Thu, 10 Apr 2025 08:41:22 +0000 (10:41 +0200)]
board: phycore-imx93: env: Add common RAUC boot logic
Add a common RAUC boot logic environment and make use of it in the
i.MX93 environment. The RAUC boot logic is deactivated by default and
can be activated by setting "doraucboot" to "1".
Signed-off-by: Martin Schwan <m.schwan@phytec.de> Reviewed-by: Leonard Anderweit <l.anderweit@phytec.de> Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
board: phycore-imx93: env: Move fdt and bootenv addresses
Move the load addresses for FDTs and bootenv.txt to create space for
loading OS image. Otherwise, parts of the image might get corrupted.
and the following boot error will be present:
Since commit 53d5a221632e ("emulation: Use bloblist to hold tables")
`make qemu-riscv64_smode_defconfig acpi.config && make` fails with
drivers/misc/qfw_smbios.c:93:(.text.qfw_evt_write_smbios_tables+0xe):
undefined reference to `bloblist_add'
Build with bloblist support.
Fixes: 53d5a221632e ("emulation: Use bloblist to hold tables") Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Since commit 53d5a221632e ("emulation: Use bloblist to hold tables")
`make qemu-riscv64_smode_defconfig acpi.config && make` fails with
qfw_acpi.c:146:(.text.evt_write_acpi_tables+0xc):
undefined reference to `bloblist_add'
Build with bloblist support.
Fixes: 53d5a221632e ("emulation: Use bloblist to hold tables") Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
firmware: scmi: smt: Interrupt communication enable
i.MX95 System Manager uses interrupt driven communication which requires
the caller to set Bit[0] of channel flags to 1. When transmission
completes and the previous general purpose interrupt has been processed
by the other core, i.MX95 System Manager will set General Purpose
Interrupt Control Register (GCR). U-Boot polls General-purpose Status
(GSR) to check if the operation is finished.
Signed-off-by: Viorel Suman <viorel.suman@nxp.com> Signed-off-by: Alice Guo <alice.guo@nxp.com> Reviewed-by: Ye Li <ye.li@nxp.com> Reviewed-by: Marek Vasut <marex@denx.de>
Rafael Beims [Fri, 28 Mar 2025 10:20:40 +0000 (11:20 +0100)]
toradex: apalis-imx6: Fix build failure when CONFIG_VIDEO_IPUV3 is enabled
If CONFIG_VIDEO_IPUV3 is enabled without also having CONFIG_IMX_HDMI
enabled, the build fails for the Apalis iMX6 board.
Fixes: 592f4aed6db7 ("arm: imx: initial support for apalis imx6") Signed-off-by: Rafael Beims <rafael.beims@toradex.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Tom Rini <trini@konsulko.com>
efi_loader: Move public cert for capsules to .rodata
commit ddf67daac39d ("efi_capsule: Move signature from DTB to .rodata")
was reverted in
commit 47a25e81d35c ("Revert "efi_capsule: Move signature from DTB to .rodata"")
because that's what U-Boot was usually doing -- using the DT to store
configuration and data. Some of the discussions can be found here [0].
(Ab)using the device tree to store random data isn't ideal though.
On top of that with new features introduced over the years, keeping
the certificates in the DT has proven to be problematic.
One of the reasons is that platforms might send U-Boot a DTB
from the previous stage loader using a transfer list which won't contain
the signatures since other loaders are not aware of internal
U-Boot ABIs. On top of that QEMU creates the DTB on the fly, so adding
the capsule certificate there does not work and requires users to dump
it and re-create it injecting the public keys.
Now that we have proper memory permissions for arm64, move the certificate
to .rodata and read it from there.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Jonathan Humphreys <j-humphreys@ti.com> # on TI sk-am62p-lp Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on AML-A311D-CC Tested-by: Raymond Mao <raymond.mao@linaro.org>
If the EFI runtime services pointers are relocated even though
relocation is skipped, it corrupts some other data resulting in some
unexpected behaviour.
In this specific case, it overwrote some page table entries resulting in
the device memory address range's mappings getting removed. Eventually,
after the completion of efi_runtime_relocate(), when a driver tries to
access its device's registers it crashes since the mappings are absent.
Calling bootefi on an address that was loaded from memory (e.g., cramfs
or SPI flash via "sf read", etc.), currently results in the EFI binary
not being able to access the EFI image device path.
For example, iPXE would fail with an error "EFI could not get loaded
image's device path: Error 0x7f39e082 (https://ipxe.org/7f39e082)".
This is due to an incomplete special-case in efi_binary_run, where a new
device path was created but not used in all required places.
Fix the in-memory special case, set the "bootefi_device_path" to the
generated "file_path".
iPXE will now boot, and report the device path as
"/MemoryMapped(0x0,0xSTART,0xLEN)"
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Michal Simek [Fri, 21 Mar 2025 10:25:48 +0000 (11:25 +0100)]
cmd: fwu: Dump custom fields from mdata structure
The commit cb9ae40a16f0 ("tools: mkfwumdata: add logic to append vendor
data to the FWU metadata") added support for adding vendor data to mdata
structure but it is not visible anywhere that's why extend fwu command to
dump it.
Adriano Cordova [Wed, 19 Mar 2025 14:45:01 +0000 (11:45 -0300)]
bootm: add support for initrd in do_bootm_efi
Pass a pointer to a memory mapped initrd and its size to
efi_binary_run. The EFI stack will register an EFI_LOAD_FILE2_PROTOCOL
for the next boot stage to access this initrd.
Adriano Cordova [Wed, 19 Mar 2025 14:44:59 +0000 (11:44 -0300)]
efi_loader: efi_load_initrd: provide a memory mapped initrd
U-Boot can pass an initrd to subsequent boot stages via the
EFI_LOAD_FILE2_PROTOCOL. The current implementation only supports
this functionality via the efi boot manager: the initrd is taken
from the load options of the BootCurrent variable. This commit adds
support for registering a memory mapped initrd, e.g. loaded from a
FIT image. For now this new method takes precedence over loading the
initrd from the BootCurrent variable (if both are present) because
the BootCurrent variable is not cleared on exiting the boot manager.
U-Boot currently reserves only 0x3000 bytes when copying the FDT
in copy_fdt(), which may not be sufficient if additional nodes
(such as FMAN firmware) are added later.
This patch uses the exisitng SYS_FDT_PAD to reserve space for FDT fixup
instead of hardcoded value.
This change prevents potential corruption when resizing FDT after
EFI boot, especially when firmware like FMAN requires additional
space.
Signed-off-by: Gabriel Nesteruk <gnesteruk@sii.pl> Signed-off-by: Pawel Kochanowski <pkochanowski@sii.pl> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Simon Glass [Thu, 6 Mar 2025 14:31:24 +0000 (07:31 -0700)]
efi_loader: Install the ACPI table from the bloblist
When BLOBLIST_TABLES is used, the ACPI tables are not currently added to
the list of EFI tables. While we don't want to create a new memory
region, we do want to tell EFI about the tables.
Fix this by covering this case. At some point the non-bloblist code can
likely be removed.
Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: 3da59ee9579 ("efi_loader: Avoid mapping the ACPI tables twice") Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
board: remove capsule update support in set_dfu_alt_info()
Now that capsule update sets the dfu_alt_info environment variable
explicitly, there is no need to support it in the set_dfu_alt_info()
function. Decouple SET_DFU_ALT_INFO from EFI_CAPSULE_FIRMWARE_FIT and
EFI_CAPSULE_FIRMWARE_RAW. For many boards, this was the only use of
set_dfu_alt_info() so remove the function entirely.
Fixes: a9e6f01a941f ("efi: Define set_dfu_alt_info() for boards with UEFI capsule update enabled") Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com> Signed-off-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> # for board/libre-computer/* Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Wadim Egorov <w.egorov@phytec.de> # for
efi_firmware: set EFI capsule dfu_alt_info env explicitly
The current implementation of EFI capsule update uses set_dfu_alt_info() to
set the dfu_alt_info environment variable with the settings it requires.
However, set_dfu_alt_info() is doing this for all DFU operations, even
those unrelated to capsule update.
Thus other uses of DFU, such as DFU boot which sets its own value for the
dfu_alt_info environment variable, will have that setting overwritten with
the capsule update setting. Similarly, any user defined value for the
dfu_alt_info environment variable would get overwritten when any DFU
operation was performed, including simply performing a "dfu 0 list"
command.
The solution is stop using the set_dfu_alt_info() mechanism to set the
dfu_alt_info environment variable and instead explicitly set it to the
capsule update's setting just before performing the capsule update's DFU
operation, and then restore the environment variable back to its original
value.
This patch implements the explicit setting and restoring of the
dfu_alt_info environment variable as part of the EFI capsule update
operation.
The fix is fully implemented in a subsequent patch that removes the capsule
update dfu_alt_info support in set_dfu_alt_info().
Michal Simek [Wed, 26 Feb 2025 22:35:45 +0000 (16:35 -0600)]
xilinx: dfu: Fill directly update_info.dfu_string
Directly fill update_info.dfu_string to prepare platforms to switch
from using dfu_alt_info variable to dfu_string which contains description
for capsule update when switch is done.
Luke Wang [Tue, 25 Mar 2025 08:29:14 +0000 (16:29 +0800)]
mmc: mmc_boot: Support Sandisk and Micron eMMC BOOT/RPMB hardware partition resizing
Current mmc bootpart-resize command only support Samsung eMMC BOOT/RPMB
hardware partition resizing. Add Sandisk and Micron eMMC BOOT/RPMB hardware
partition resizing support. The commands and parameters for resizing
partitions are different for each manufacturer. Select the corresponding
function according to CID.
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Simon Glass [Sun, 16 Feb 2025 12:55:59 +0000 (05:55 -0700)]
mmc: Avoid uniniting twice
Each MMC device has a child which ihs a block device. At present we call
mmc_deinit() when the block device is removed.
But the MMC struct (i.e. struct mmc) is attached to the MMC's device,
not its child.
So at present, when an MMC device is removed, mmc_deinit() is called
twice, once for the MMC device and once for its block device. This
results in a double call to cyclic_unregister().
Fix this by adding a 'remove' method to the uclass and calling
mmc_deinit() from there.
Also drop the call to device_probe() within the block-device's probe()
method. The device is already in the process of being probed, so this
call does nothing.
Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: c822c1a50bd ("mmc: call device_probe() after scanning") Signed-off-by: Peng Fan <peng.fan@nxp.com>
Jonas Karlman [Thu, 23 Jan 2025 21:48:48 +0000 (21:48 +0000)]
mmc: sdhci: Fix possible Synchronous Abort using PIO mode
When MMC_SDHCI_SDMA=y or MMC_SDHCI_ADMA=y and PIO mode is used
dma_unmap_single() is called on an unmapped address, 0x0. This may
result in a Synchronous Abort:
Peng Fan [Mon, 20 Jan 2025 04:30:09 +0000 (12:30 +0800)]
mmc: Optimize eMMC erase speed
Per JESD84-B51 6.6.9 Erase:
The host can erase a contiguous range of Erase Groups. Starting the erase
process is a three steps sequence. First the host defines the start address
of the range using the ERASE_GROUP_START (CMD35) command, next it defines
the last address of the range using the ERASE_GROUP_END (CMD36) command and
finally it starts the erase process by issuing the ERASE (CMD38) command
with argument bits set to zero. See Table 11 for the arguments supported by
CMD38. The address field in the erase commands is an Erase Group address,
in byte units for densities up to 2GB, and in sector units for densities
greater than 2GB. The Device will ignore all LSB's below the Erase Group
size, effectively rounding the address down to the Erase Group boundary.
So choose 2GB bytes as check condition.
If the erase size is larger that 2GB, use 2GB to avoid breaking non high
capacity cards. If erase size is less than 2GB and larger than a grp, use
'grpcnt * mmc->erase_grp_size' to cover all the sectors, else use
the number of sectors.
Marek Vasut [Sat, 18 Jan 2025 03:09:53 +0000 (04:09 +0100)]
mmc: Simplify poll CD logic in case cyclic framework is enabled
Simplify 90cc07fd786d ("mmc: Poll CD in case cyclic framework is enabled")
according to suggestions by Rasmus. The struct cyclic_info is zero-size in
case CONFIG_CYCLIC is not enabled and does not add any size to struct mmc,
so it can unconditionally be part of that structure. This allows clean up
of all the other conditionals in mmc.c which can now be unconditionally
present, as they also add no extra space.
Suggested-by: Rasmus Villemoes <ravi@prevas.dk> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Peng Fan <peng.fan@nxp.com>
The option MMC_SDHCI_ADMA_FORCE_32BIT is only tested or used when
MMC_SDHCI_ADMA or SPL_MMC_SDHCI_ADMA is enabled. And for
MMC_SDHCI_ADMA_64BIT the same is true except we also require
MMC_SDHCI_ADMA_FORCE_32BIT to be disabled.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Acked-by: Peng Fan <peng.fan@nxp.com>
Daniel Golle [Sat, 29 Mar 2025 23:23:51 +0000 (23:23 +0000)]
image-fit-sig: skip in tools build if key is missing
Skip signature verification in case no public key was given in order to
allow using fit_check_sign also to validate uImage.FIT images without
signatures. Guarded by USE_HOSTCC macro the behavior on target is
unchanged.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
As current design, only Manager CPU called armv8_setup_psci() before
jump to next stage(such as Linux Kernel), Subordinate CPUs also need
setup psci vector to handle trap request which comes from higher EL
level.
Signed-off-by: Xu Zhang <423756212@qq.com>
[trini: Guard with !CONFIG_XPL_BUILD check]
Add support for the LCD interfaces (LCDIF1/2). When probed, these
interfaces request numerous clocks and power domains, attach the bridge
and look for a panel in order to retrieve its capabilities and
properties.
There is a similar existing driver in the upper folder for other i.MX
targets, I discovered this driver a bit late. It is not targeting the
i.MX8MP and I have no idea how different can the LCDIF be on this SoC,
but I did not manage to get it work, especially because it is not fully
compliant with the device-model, especially on the clocks/power
management side which is all ad-hoc. This is normal though, it was
contributed more than ten years ago.
Add support for the LVDS Display Bridge (LDB) found on i.MX8MP.
When attached, the bridge driver looks for panels connected to one of
its two outputs and adapts its own configuration to use them. There is
currently no support for merged/split displays.
Note regarding the clock configuration:
The LDB output clock should be absolutely identical to the LCDIF output
clock so both blocks can talk to each other synchronously. However, the
LDB clock has an internal divisor of 7 (respectively 3.5 in dual
configuration) which means the LDB input clock must be explicitly set
once we know the configuration.
This driver was tested on i.MX8MP using a single panel connected to the
LVDS2 interface.
video: imx: Fix Makefile in order to be able to add other imx drivers
The IPUv3 is one IP part of the imx world, there are others, and
selecting the whole imx/ folder based on such a specific Kconfig symbol
is sub-optimal. Let's always enter the imx/ folder, and then selectively
compile parts of the folder based on the configuration.
These are all the clocks needed to get an LCD panel working, going
through one of the LCDIF and the LDB. The media AXI and APB clocks are
also described.
clk: Ensure the parent clocks are enabled while reparenting
Reparenting a clock C with a new parent P means that C will only
continue clocking if P is already clocking when the mux is updated. In
case the parent is currently disabled, failures (stalls) are likely to
happen.
This is exactly what happens on i.MX8 when enabling the video
pipeline. We tell LCDIF clocks to use the VIDEO PLL as input, while the
VIDEO PLL is currently off. This all happens as part of the
assigned-clocks handling procedure, where the reparenting happens before
the enable() calls. Enabling the parents as part of the reparenting
procedure seems sane and also matches the logic applied in other parts
of the CCM.
It is very surprising that such an uclass, specifically designed to
handle resources that may be shared by different devices, is not keeping
the count of the number of times a power domain has been
enabled/disabled to avoid shutting it down unexpectedly or disabling it
several times.
Doing this causes troubles on eg. i.MX8MP because disabling power
domains can be done in recursive loops were the same power domain
disabled up to 4 times in a row. PGCs seem to have tight FSM internal
timings to respect and it is easy to produce a race condition that puts
the power domains in an unstable state, leading to ADB400 errors and
later crashes in Linux.
CI tests using power domains are slightly updated to make sure the count
of on/off calls is even and the results match what we *now* expect.
As we do not want to break existing users while stile getting
interesting error codes, the implementation is split between:
- a low-level helper reporting error codes if the requested transition
could not be operated,
- a higher-level helper ignoring the "non error" codes, like EALREADY and
EBUSY.
test: dm: test-fdt: Add checks for uclass_get_device_by_endpoint()
This is a new DM core helper. There is now a graph endpoint
representation in the sandbox test DTS, so we can just use it to verify
the helper proper behavior.
Suggested-by: Simon Glass <sjg@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
dm: core: Add a helper to retrieve devices through graph endpoints
There are already several helpers to find a udevice based on its
position in a device tree, like getting a child or a node pointed by a
phandle, but there was no support for graph endpoints, which are very
common in display pipelines.
Add a new helper, named uclass_get_device_by_endpoint() which enters the
child graph reprensentation, looks for a specific port, then follows the
remote endpoint, and finally retrieves the first parent of the given
uclass_id.
This is a very handy and straightforward way to get a bridge or a panel
handle.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Andre Przywara [Tue, 25 Mar 2025 17:47:44 +0000 (17:47 +0000)]
common: console: move break; statement
In console_setfile(), there is some #ifdef'ed code, updating monitor
functions for a U-Boot proper build. This is called inside a switch/case
statement, but the closing "break;" is inside the #ifdef section.
This doesn't look right: we should not fall through to the error case
for an SPL/TPL build.
Move the "break" to be always effective, solving a compiler warning about
an untagged implicit fallthrough.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Tom Rini [Thu, 10 Apr 2025 21:04:09 +0000 (15:04 -0600)]
Merge patch series "*** Add Ethernet boot support for AM62Ax + phyCORE-AM62 SoMs ***"
Wadim Egorov <w.egorov@phytec.de> says:
Add general ethernet boot support for AM62Ax SoC.
Some of the work is based on TI's downstream u-boot patches found in
[1], patches touching code in mach-k3 and *.yaml board config files.
Also, provide defconfigs and device tree changes for phyCORE-AM62x and
phyCORE-AM62Ax to support booting via ethernet.
Nathan Morrisson [Tue, 25 Mar 2025 03:58:23 +0000 (04:58 +0100)]
board: phytec: phycore_am62ax: Share ethernet resources with boot r5 core
During the U-Boot SPL R5 boot stage the code is running on the MAIN R5
core, which means a host ID of 36 is used for DM/TIFS communication,
see [1]. In order to enable Ethernet boot update the DMA resources used
to be shared with the MAIN R5 core instead of the MCU R5 core.
Wadim Egorov [Tue, 25 Mar 2025 03:58:18 +0000 (04:58 +0100)]
configs: Add phycore_am62x_r5_ethboot_defconfig
Provide a defconfig for booting the phycore-am62x via Ethernet.
We need a separate defconfig because the AM62x has not enough internal
SRAM to support all boot sources.
Wadim Egorov [Tue, 25 Mar 2025 03:58:17 +0000 (04:58 +0100)]
arm: dts: k3-am625-phyboard-lyra-rdk: Add boot phase tag to phy_gmii_sel
Add bootph-all tag to phy_gmii_sel node. This is needed for booting via
Ethernet. While at it, drop main_pktdma reg redefinitions which are already
provided by the top-level SoC device tree file.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Tested-by: Daniel Schultz <d.schultz@phytec.de>
Tom Rini [Thu, 10 Apr 2025 20:21:46 +0000 (14:21 -0600)]
Merge patch series "scsi: ensure writes are flushed to disk"
Caleb Connolly <caleb.connolly@linaro.org> says:
SCSI devices like UFS may maintain their own cache to speed up writes,
however this is lost on board reset (and may be lost on device removal
or reset by OS drivers).
Currently this can be worked around by "waiting for a while" after
writing data to disk, but of course this is not an acceptable solution.
Ideally U-Boot would have a mechanism to flush caches during board
reset, but until that logic is hooked up let's be sure that all writes
are actually propagated to the storage device so that we don't lose data
on board reset.
The same logic was already implemented just for the AHCI backend, this
duplicated logic has been removed and support for the SYNC_CACHE command
is added to AHCI.
This is particularly noticeable during capsule updates, since the update
file is deleted and the board is reset immediately afterwards which
resulted in the same capsule update being applied over and over again.
This specifically fixes Qualcomm SDM845 devices with UFS 2.1, but likely
all UFS devices that use a cache.
Caleb Connolly [Wed, 26 Mar 2025 12:24:10 +0000 (13:24 +0100)]
ata: ahci: implement SCSI_SYNC_CACHE
The SCSI layer now issues a SYNC_CACHE command after every write to
ensure there is no data loss due to a board reset after write.
Implement support for this command and remove the same logic from the
ATA write path to be consistent with other SCSI backends.
Ranges are not supported and the whole cache will be flushed in all
cases.
This was done per iteration in ata_scsiop_read_write(), but it's not
clear why this was the case, calling it once for the entire write ought
to achieve the same result.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Caleb Connolly [Wed, 26 Mar 2025 12:24:09 +0000 (13:24 +0100)]
scsi: sync cache on write
We don't have a mechanism to safely shutdown block devices prior to a
baord reset or driver removal. Prevent data loss by synchronizing the
SCSI cache after every write.
In particular this solves the issue of capsule updates looping on some
devices because the board resets immediately after deleting the capsule
file and this write wouldn't be flushed in time.
This may impact NAND wear, but should be negligible given the usecases
for disk write in U-Boot.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
projects / thirdparty / u-boot.git / log
