| Age | Commit message (Collapse) | Author |
|---|
|
Add support for jumping to Linux kernel through OPTEE-OS on ARMv7a to SPL.
This is already supported on ARMv8a, this patch adds the ARMv7a support.
Extend the SPL fitImage loader to record OPTEE-OS load address and in case
the load address is non-zero, use the same bootm-optee.S code used by the
U-Boot fitImage jump code to start OPTEE-OS first and jump to Linux next.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Add support for jumping to Linux kernel through OPTEE-OS on ARMv7a.
This is only supported if U-Boot runs in PL1 secure. This change adds
two components, one is fitImage OPTEE-OS loadable handler, which makes
a note of OPTEE-OS being loaded and stores the load address for later
jump to it. The second part is the actual jump to Linux through OPTEE-OS.
The jump through OPTEE-OS requires set up of multiple CPU registers, r1
and r2 are passed through, r0 and r3 have to be set to 0, lr is set to
Linux kernel entry point. This setup is done by new assembler function
boot_jump_linux_via_optee().
The boot_jump_linux_via_optee() also includes STM32MP13xx late TZC
configuration write, this cannot be moved easily, hence the ifdef.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Make sure to pass Clang flags to the KBUILD_CPPFLAGS as well, as this
variable is used for flags during compiling for target
Skipping this leads to Clang being invoked with args for target, but
without target indication, thus defaulting to host arch:
LDS u-boot.lds
clang: error: ... '-mabi=' for target 'x86_64-suse-linux'
clang: error: ... '-mno-thumb' for target 'x86_64-suse-linux'
clang: error: ... '-mno-unaligned-access' for target 'x86_64-suse-linux'
clang: error: ... '-ffixed-r9' for target 'x86_64-suse-linux'
clang: error: ... '-mno-movt' for target 'x86_64-suse-linux'
make: *** [Makefile:2345: u-boot.lds] Fehler 1
Signed-off-by: Dmitrii Sharshakov <[email protected]>
|
|
This option is not available for 32-bit ARM targets and causes an error
when building with Clang:
clang: error: unsupported option '-mgeneral-regs-only' for
target 'arm-none-eabi'
This fixes the following patch (also seems to only concern AArch64):
Link: https://lists.denx.de/pipermail/u-boot/2021-August/458067.html
Signed-off-by: Dmitrii Sharshakov <[email protected]>
|
|
When spl boot device list has multiple FAT devices, any previousely
registered FAT device should be deregistered before registering
next FAT boot device, otherwise the function may not attempt boot
from next FAT device.One of the situations where this issue can be
observed is when the boot device list has two FAT partitions of a
memory device and if booting fails on first partition (because of
file or partition related errors), boot from next partition actually
gets attempted on previous boot device only, as the previous device
has remained marked as registered. Call the function that invalidates
cached boot device in case of failure in booting from current FAT
boot device.
Signed-off-by: Prasad Kale <[email protected]>
Cc: Dan Murphy <[email protected]>
Cc: Sean Anderson <[email protected]>
|
|
Align the implementation to rsa_add_verify_data() by writing the modulus
and r-squared properties with the same length as the key itself. This
fixes signature verification issues when one of the parameters has
leading zeros.
Reported-by: Hans Gfirtner (Nokia) <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
|
|
Technically, commit 24bf44cf88e7 ("spl: fit: Do not fail immediately if
an overlay is not available") introduced that regression as the code
will never advance if spl_fit_get_image_name() will return an error. But
at that time, spl_fit_get_image_node() was used in spl_fit_append_fdt()
which calls fdt_subnode_offset() to get the image node. And I presume
the commit was about the latter failing gracefully and trying the next
one.
But with commit b13eaf3bb4e6 ("spl: fit: Add board level function to
decide application of DTO") that behavior changed and the loop in
spl_fit_append_fdt() no longer uses spl_fit_get_image_node() but
spl_fit_get_image_name() directly. Thus it doesn't make any sense to not
break the loop if that fails.
Also, the original use case of commit 24bf44cf88e7 ("spl: fit: Do not
fail immediately if an overlay is not available") is preserved because
spl_subnode_offset() is now called within the loop and errors are
handled gracefully (and advancing the index).
Fixes: b13eaf3bb4e6 ("spl: fit: Add board level function to decide application of DTO")
Signed-off-by: Michael Walle <[email protected]>
|
|
The U-Boot project has been assigned the vendor ID 'UBOO' [1]. Use this
vendor ID and our release version in the ACPI table headers.
[1] ACPI ID Registry
https://uefi.org/ACPI_ID_List
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
In Azure, older pipelines such as ours do not default to a shallow fetch
but rather do a complete clone. This introduces a marginal time increase
in each task, but also more importantly takes up significant disk space.
We are now getting warnings in some cases about using more than 95% of
our available disk space so take this as a first easy step to resolve
that problem.
Signed-off-by: Tom Rini <[email protected]>
|
|
Rockchip boards may depend on a working MMC regulator in SPL to
successfully load FIT payload from MMC. Typically, these boards only
include the vmmc-supply regulator and not its vin-supply in SPL control
FDT.
The commit f98d812e5353 ("power: regulator: Add vin-supply for GPIO and
Fixed regulators") breaks loading FIT from MMC in SPL on some of these
boards due to now requiring the vin-supply to be included in the SPL
control FDT.
The commit also strangely enables any found vin-supply in
regulator_common_of_to_plat() and not when a regulator is enabled or as
part of regulator_autoset().
Revert the commit to fix FIT loading in SPL on broken boards.
If a board needs to have its vin-supply enabled, two options come to
mind:
- Add regulator-always-on prop to the regulator in the -u-boot.dtsi for
any board.
- Implement full support for reference counting of regulators and then
update the regulator-uclass to enable any found vin-supply when a
regulator is enabled.
This reverts commit f98d812e5353408ef77a46bad1f1cdc793ff8a03.
Reported-by: Dang Huynh <[email protected]>
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Dragan Simic <[email protected]>
|
|
If CONFIG_GPIO_HOG is not set, then gpio_hog_lookup_name() is empty,
and thus does not initialize any of its parameters. It does still
return 0 though, and so any calling function might assume that the
parameters have been initialized successfully.
Change the return value to -ENODEV in this case, as the function
would in the case when CONFIG_GPIO_HOG is set but the gpio hog
could not be found.
Signed-off-by: Wolfgang Wallner <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
In devices where the U-Boot is used as a secondary bootloader, we rely
on the device's primary bootloader to implement CNTFRQ_EL0. However,
this reliance may lead to a non-functional timer in broken firmware.
For instance, some versions of Samsung's S-Boot don't implement it. It's
also not possible to set it in the U-Boot, because it's booted in a lower
exception level. CNTFRQ_EL0 is reported to be 0.
Use gd->arch.timer_rate_hz to override the queried value if set. This
setting needs to be done in the board file, preferrably in timer_init().
This feature is present only when the CONFIG_ARMV8_CNTFRQ_BROKEN is
enabled.
Signed-off-by: Kaustabh Chakraborty <[email protected]>
|
|
When previously using script based bootflows, the U-Boot
environment variable bootargs was used to customize the kernel
commandline at boot time.
In order to get the same behaviour, concatenate the bootflow
commandline with the contents the bootargs environment variable.
Signed-off-by: Nicolas Belin (TI.com) <[email protected]>
Signed-off-by: Guillaume La Roque (TI.com) <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Introduces support for Device Firmware Upgrade (DFU) over PCIe in
U-Boot. Traditionally, the DFU protocol is used over USB, where a
device enters DFU mode and allows a host to upload firmware or binary
images directly via the USB interface. This is a widely adopted and
convenient method for updating firmware.
In the context of Texas Instruments (TI) SoCs, PCIe can be used as a
boot interface in a manner that differs from the conventional
"PCIe Boot" process, which typically refers to booting an OS or
firmware image from an NVMe SSD or other PCIe-attached storage devices.
Instead, TI SoCs can be configured as a PCIe Endpoint, allowing a
connected PCIe Root Complex (host) to transfer images directly into the
device’s memory over the PCIe bus for boot purposes. This mechanism is
analogous to DFU over USB, but leverages the high-speed PCIe link and
does not depend on traditional storage devices.
By extending the DFU framework in U-Boot to support PCIe, it will be
possible to flash images over PCIe. While this implementation is
motivated by TI SoC use cases, the framework is generic and can be
adopted by everyone for platforms that support PCIe Endpoint mode.
Platforms with hardware support for PCIe-based memory loading can use
this to implement PCIe as a boot mode, as well as to enable flashing
and recovery scenarios similar to DFU over USB.
In summary, enable support for:
- DFU-style flashing of firmware/images over PCIe, analogous to existing
USB DFU workflows
- PCIe as a boot mode where a host can load images directly into device
memory using DFU over PCIe
Signed-off-by: Hrushikesh Salunke <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
https://gitlab.denx.de/u-boot/custodians/u-boot-imx
CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/28144
- Extend USB support for the i.MX9 family.
- Update memory controller for imx6ulz_smm_m2.
- Add remoteproc support for several i.MX boards.
- Add support for iMX95 15x15 EVK.
|
|
Now that we have a test for QEMU using transfer list from the previous
stage, there are two platforms testing this particular infrastructure. A
problem with the vexpress_fvp platform emulation in Gitlab is that we
often run it on hosts that are fast enough that we run in to a race
condition when trying to acquire the console and the test fails. Remove
both vexpress_fvp tests from Gitlab (they can remain in Azure) to remove
these spurious failures.
Signed-off-by: Tom Rini <[email protected]>
|
|
This also incorporates the following commits to the Dockerfile:
da7942de29f7 Dockerfile: remove Python 2.7
183299d9a400 docker: add OP-TEE and TF-A build for testing Firmware Handoff
Signed-off-by: Tom Rini <[email protected]>
|
|
We don't use Python 2 anywhere. Remove the package from our Docker image.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Raymond Mao <[email protected]> says:
This patch series enable Firmware Handoff [1] CI tests on qemu_arm64 by:
1. fetch MbedTLS (v3.6), OP-TEE (v4.7.0) and TF-A (v2.13.0);
2. build bl1 and fip with both Firmware Handoff and Measured Boot
enabled;
3. pytest to validate the Firmware Handoff feature via bloblist by
checking the existence of expected FDT nodes and TPM events generated
and handed over from TF-A/OP-TEE.
[1] https://github.com/FirmwareHandoff/firmware_handoff
Link: https://lore.kernel.org/r/[email protected]
|
|
Add qemu_arm64_tfa_fw_handoff test entries to azure and gitlab
pipelines.
Signed-off-by: Raymond Mao <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Check the existence of bl1 and fip from:
1. /opt/tf-a/${board_type}_${board_ident}, if not exist, then;
2. /opt/tf-a/${board_type}
This change allows to test with TF-A with specified board ID only.
Signed-off-by: Raymond Mao <[email protected]>
|
|
Firmware Handoff tests will leverage the same board type 'qemu_arm64'
with a new board ID 'fw_handoff_tfa_optee', thus select CMD_BLOBLIST
in qemu_arm64_defconfig for running the test.
Signed-off-by: Raymond Mao <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Add test cases to validate FDT and TPM eventlog handoff from TF-A
and OP-TEE via bloblist.
For FDT, the nodes 'reserved-memory' and 'firmware' appended by
OP-TEE indicates a successful handoff.
For TPM eventlog, the events 'SECURE_RT_EL3', 'SECURE_RT_EL1_OPTEE'
and 'SECURE_RT_EL1_OPTEE_EXTRA1' created by TF-A indicates a
successful handoff.
Signed-off-by: Raymond Mao <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Fetch OP-TEE (4.7.0), TF-A (v2.13.0), MbedTLS (v3.6) and build
bl1 and fip with both Firmware Handoff and Measured Boot enabled.
Signed-off-by: Raymond Mao <[email protected]>
Acked-by: Jerome Forissier <[email protected]>
|
|
mem_map_from_dram_banks calls fdtdec_setup_memory_banksize to setup the
dram banks though that is expected to be done by dram_init_banksize as
part of board_r sequence.
This has the side effect of modifying gd->bd->bi_dram as well, therefore
this patch removes the call and updates spl_enable_cache for K3 to call
dram_init_banksize.
Signed-off-by: Anshul Dalal <[email protected]>
Reported-by: Francesco Dolcini <[email protected]>
Closes: https://lore.kernel.org/u-boot/20251027165225.GA71553@francesco-nb/
Fixes: fe2647f2a0d4 ("arm: armv8: mmu: add mem_map_from_dram_banks")
Tested-by: Emanuele Ghidoli <[email protected]>
|
|
Add boot support and peripherals like eMMC/SD, UART, I2C, GPIO, ENETC0/1
and PCIE0/1 for iMX95 15x15 LPDDR4X EVK.
Updated doc for build instructions.
Signed-off-by: Ye Li <[email protected]>
|
|
Add -u-boot.dtsi for iMX95 15x15 EVK used by SPL and binman.
iMX95 15x15 EVK uses LPDDR4X which needs dedicated DDR FW.
Signed-off-by: Ye Li <[email protected]>
|
|
Rename the env file to imx95_evk.env to share it with iMX95 15x15 EVK
Signed-off-by: Ye Li <[email protected]>
|
|
The factory provides a CPU UID in the OTPs and the SoM module
and the carrier board might provide additional UIDs in the GP
registers of the OTPs. Load these values in the following order
and create a serial number string:
* Board UID (GP2)
* SoM UID (GP1)
* CPU UID (UNIQUE_ID)
The string is stored in the "serial#" env variable and
exported to Linux. Further this prints the used UID to the
console which looks like this
ID: 0042152331 (Board)
or:
ID: 0030124840 (SoM)
or:
ID: 4696668CD9516886 (CPU)
Signed-off-by: Frieder Schrempf <[email protected]>
|
|
The factory provides a CPU UID in the OTPs and the SoM module
and the carrier board might provide additional UIDs in the GP
registers of the OTPs. Load these values in the following order
and create a serial number string:
* Board UID (GP2)
* SoM UID (GP1)
* CPU UID (UNIQUE_ID)
The string is stored in the "serial#" env variable and
exported to Linux. Further this prints the used UID to the
console which looks like this
ID: 0042152331 (Board)
or:
ID: 0030124840 (SoM)
or:
ID: 4696668CD9516886 (CPU)
Signed-off-by: Frieder Schrempf <[email protected]>
|
|
The factory provides a CPU UID in the OTPs and the SoM module
and the carrier board might provide additional UIDs in the GP
registers of the OTPs.
Provide a common function to load UIDs from arbitrary OTP
registers and generate a serial number string that is saved
in the "serial#" env variable.
Signed-off-by: Frieder Schrempf <[email protected]>
|
|
Recently code was added in board_late_init() to autostart fastboot
in case of booting from USB OTG. This change was ineffective as
enabling CONFIG_BOARD_LATE_INIT got lost during upstreaming.
Fixes: 410d9ccc0388 ("imx: kontron-sl-mx6ul: Autostart fastboot if booted from USB")
Signed-off-by: Frieder Schrempf <[email protected]>
|
|
This allows to print user-friendly names for the boot device
probed by SPL to the console.
Signed-off-by: Frieder Schrempf <[email protected]>
|
|
The image offset on SD/MMC devices is 33 KiB, except for eMMC boot if
fastboot is enabled. In this case it is 1 KiB. In order to make the
the bootloader universal, check the fastboot OTP boot fuse and adjust
the offset.
Signed-off-by: Frieder Schrempf <[email protected]>
|
|
Add documentation for rproc cmd usage.
Signed-off-by: Peng Fan <[email protected]>
|
|
Add guide on how to use the Remote Processors on i.MX8M and i.MX93.
Update MAINTAINERS to include doc/board/nxp.
Signed-off-by: Peng Fan <[email protected]>
|
|
Select configs to enable remoteproc for i.MX93-EVK/QSB/FRDM
Reviewed-by: Ye Li <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Select configs to enable remoteproc for i.MX8MQ EVK
Reviewed-by: Ye Li <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Select configs to enable remoteproc for NXP i.MX8MN EVK boards
Reviewed-by: Ye Li <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Select configs for remoteproc on i.MX8MM EVK boards
Reviewed-by: Ye Li <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Select configs to enable remoteproc for NXP i.MX8MP EVK
Reviewed-by: Ye Li <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Add CM7/4 nodes for i.MX8MQ/M/N/P.
Reviewed-by: Ye Li <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Introduce remote processor configuration for the i.MX93 Cortex-M33 core.
This patch adds:
- Address translation table (ATT) for i.MX93, including TCM
(secure and non-secure) and DDR regions.
- A new device configuration structure `imx_rproc_cfg_imx93` using SMC
method and ARM SMC ops.
- Device tree match entry for "fsl,imx93-cm33"
This enables remoteproc framework to properly initialize and manage the
Cortex-M33 core on i.MX93 platforms.
Reviewed-by: Ye Li <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
i.MX8MQ/M use MMIO based method to directly configure SRC registers
to start/stop M4.
Add mmio ops to start/stop/is_running.
Add i.MX8MQ cfg data, i.MX8MN reuses i.MX8MQ data.
Reviewed-by: Ye Li <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Support i.MX8MP/N with start/stop/device_to_virt/is_running/load
implemented. The device static configuration is mostly reused from
Linux Kernel with adapation to U-Boot dm_rproc_ops.
The booting method:
- load mmc 2:2 0x90000000 /lib/firmware/imx8mp_m7_DDR_rpmsg_lite_str_echo_
rtos.elf
- rproc load 0 0x90000000 ${filesize}
- rproc start 0
Reviewed-by: Ye Li <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Some areas needs to be initialized by using memcpy_toio and memset_io.
Following Linux Kernel commit: 40df0a91b2a5 ("remoteproc: add is_iomem to
da_to_va"), add this to U-Boot.
Reviewed-by: Ye Li <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Plus DHCOM on PDK2
The LED enumerators are missing, which prevents the LEDs from being
accurately told apart by label. Fill in the enumerators the same way
they are already present on PDK3. Put this into local DT extras until
matching kernel patch lands in Linux.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
|
|
non-cacheable
This patch splits the 2MB SRAM0 mapping into three regions:
- 0x22000000~0x2201f000: cacheable normal memory
- 0x2201f000~0x22020000: non-cacheable device memory
- 0x22020000~0x22200000: cacheable normal memory
The change ensures the SCMI shared memory is non-cacheable, which
avoids cache-related issues after removing
mmu_set_region_dcache_behaviour() from scmi_dt_get_smt_buffer().
Signed-off-by: Alice Guo <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
|
|
Enable DFU SF on all i.MX6 DHSOM so the SPI NOR can be exposed via
DFU, and include dfu_alt_info which exposes the full SPI NOR via DFU.
To install new bootloader into the SPI NOR using DFU, it is necessary
to pad the u-boot-with-spl.imx to 0x400 Bytes offset first and then
send it to the board as follows:
"
u-boot=> dfu 0 sf
"
"
host$ dd if=/dev/zero of=pad.bin bs=1024 count=1
host$ cat pad.bin u-boot-with-spl.imx > flash.bin
host$ dfu-util -w -a 0 -D flash.bin
"
Signed-off-by: Marek Vasut <[email protected]>
|
|
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
|
