Marek Vasut [Wed, 29 Jan 2025 11:15:54 +0000 (12:15 +0100)]
mmc: Fix size calculation for sector addressed MMC version 4
For eMMC v4 and newer that is smaller than 2 GiB, the JEDEC JESD84-B51
section 6.2.4 Configure partitions indicates that EXT_CSD SEC_COUNT
should not be used to determine device size, and instead device size
should be calculated from C_SIZE and C_SIZE_MULT.
This is not exactly accurate, the 2 GiB limit is not a hard line,
there are eMMC devices which are smaller than 2 GiB and still
require device size to be determined from EXT_CSD SEC_COUNT. The
hard line is instead OCR HCS bit, which indicates whether the device
is byte or sector addressed, the former applies to most devices
below 2 GiB, and the later applies mostly to devices above 2 GiB.
However, there are a couple of devices which are smaller than 2 GiB
and still set the OCR HCS bit to indicate they are sector addressed,
and therefore the size calculation for those devices should also
use EXT_CSD SEC_COUNT . Use mmc->high_capacity flag to discern the
devices instead of arbitrary 2 GiB limit. The mmc->high_capacity flag
reflects the OCR HCS bit state.
Fixes: 639b7827d1ca ("mmc: fix the condition for MMC version 4") Signed-off-by: Marek Vasut <marex@denx.de>
The length of buffers used to read inode tables, directory tables, and
reading a file are calculated as: number of blocks * block size, and
such plain multiplication is prone to overflowing (thus unsafe).
Replace it by __builtin_mul_overflow, i.e. safe math.
Signed-off-by: Joao Marcos Costa <joaomarcos.costa@bootlin.com>
Tom Rini [Sat, 22 Feb 2025 14:42:01 +0000 (08:42 -0600)]
Merge branch 'picasso' of https://source.denx.de/u-boot/custodians/u-boot-tegra
Branch contains bringup of Acer Iconia Tab A500 (codename picasso), a
Tegra 2 Android device with decent Linux kernel support. Ondevice tests
and U-Boot test suit all passed.
Tom Rini [Fri, 21 Feb 2025 14:34:34 +0000 (08:34 -0600)]
Merge patch series "Add preload_check_sign tool"
Paul HENRYS <paul.henrys_ext@softathome.com> says:
This serie of patches adds a new tool to authenticate files signed
with a preload header.
This tool is also used in the tests to actually verify the
authenticity of the file signed with such a preload header.
Tom Rini [Fri, 21 Feb 2025 14:24:49 +0000 (08:24 -0600)]
Merge branch 'fix-issues-and-update-pylint-version' into next
This merges a set of patches from myself and Simon Glass to resolve
various problems that the current version of pylint will report with our
codebase. After the problems are fixed, we update to the now current
version which is 3.3.4.
Udit Kumar [Thu, 13 Feb 2025 09:23:22 +0000 (14:53 +0530)]
remoteproc: k3-dsp: Flush D cache after loading firmware
Memory region used by remote cores was set to non-cached region but
commit 7c9c6e192580 ("arm: mach-k3: Merge initial memory maps") makes
all memory region as cached, unified across K3 devices.
This causes inconsistency while booting remote cores on devices, due to
cache incoherency between remote core and boot code.
So to make this operation coherent, cache the address and len while
loading ELF program headers to memory and flush that region in the next
cycle of load.
Paul HENRYS [Wed, 12 Feb 2025 09:31:24 +0000 (10:31 +0100)]
tools: Add preload_check_sign to authenticate images with a pre-load
preload_check_sign is added so that it can be used to authenticate images
signed with the pre-load signature supported by binman and U-Boot.
It could also be used to test the signature in binman tests signing
images with the pre-load.
Signed-off-by: Paul HENRYS <paul.henrys_ext@softathome.com>
Tom Rini [Wed, 12 Feb 2025 22:23:54 +0000 (16:23 -0600)]
test/py: Have test_usb.py raise an Exception with unsupported filesystems
With a newer pylint we get a warning about how offset could be used
before assigned. This is because when the underlying filesystem wasn't
one that is supported we would have runtime test failures. Address this
by raise'ing an Exception if fs is not supported.
Tom Rini [Wed, 12 Feb 2025 22:24:00 +0000 (16:24 -0600)]
test/py: Rework how test_ums.py handles (not) having write enabled
With a newer pylint version we get a warning about how mounted_test_fn
could be used before assignment. Evaluating the code, this can't happen
because we check for "not have_writable_fs_partition" and return before
moving to the part of the tests which use mounted_test_fn. However, we
should instead have this written so that we only try this part of the
test if have_writable_fs_partition is set, and this also fixes the
warning. As part of this we also move test_f and mounted_test_fn to the
section of code that already only does this if
have_writable_fs_partition is set.
Tom Rini [Wed, 12 Feb 2025 22:24:07 +0000 (16:24 -0600)]
test/py: Rework test_spi.py to assert we found output
When running a newer version of pylint it will complain that page_size
may be used before being assignment. Looking deeper what is going on is
that we could run in to the case where the regex we run for any of the
flash information fails but since we don't have a result, we don't check
it either. In the case of the rest of the numerical values we then have
some assignment (multiplying by some value) and so pylint doesn't
complain. Rework things to assert that each regex has a result and so
failure will stop the test and we won't have any use before assignment.
Tom Rini [Thu, 20 Feb 2025 22:14:53 +0000 (16:14 -0600)]
Merge patch series "FIT Image Boot Fixes for am57xx_hs_evm"
Anurag Dutta <a-dutta@ti.com> says:
The u-boot is unable to load the FIT image due to incorrect
boot arguments in case of am57_hs evm as can be seen in [1].
This series introduces multiple changes pertaining to several
environment variables and overlays that are responsible for
successful [2] loading of kernel image.
Sinthu Raja [Tue, 11 Feb 2025 09:49:30 +0000 (15:19 +0530)]
configs: omap5: Enable custom mmc boot to distroboot for AM57x
TI AM57x boards use a custom (though family common to TI boards) mechanism
for booting Linux. Add support to enable custom MMC boot as a default
option along with the distroboot approach.
Also, add supporting mmc boot environment variables which shall be used for
custom MMC boot
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com> Signed-off-by: Anurag Dutta <a-dutta@ti.com>
Sinthu Raja [Tue, 11 Feb 2025 09:49:29 +0000 (15:19 +0530)]
include: configs: Override get_fit_config to get FIT config for AM57x
Kernel commit 837833a724b7 ("environment: ti: Add get_fit_config command
to get FIT config string") introduced "get_fit_config" in ti_armv7_common.h
to mangle the fdtfile name when used to select a config node from the OE
made FIT image. However, the ti_armv7_common.h is common for both K3 and
AM57xx platforms. AM57xx platforms' fdtfile name does not have '/' and
"conf-" prefix so the setexpr command fails and boot hangs.
Override the get_fit_config in AM57x specific config header to get the
correct FIT config name.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com> Signed-off-by: Anurag Dutta <a-dutta@ti.com>
Daniel Schultz [Mon, 10 Feb 2025 15:25:48 +0000 (07:25 -0800)]
board: Phytec: phycore_am62x: Increase size for Image in SPI
Increase the maximum Image size from 23 MB to 26 MB by moving the
initramfs start address up. This gives us a bigger ranger to
provide kernel images which are not stripped down too much.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Daniel Schultz [Mon, 10 Feb 2025 15:25:47 +0000 (07:25 -0800)]
board: Phytec: phycore_am64x: Increase size for Image in SPI
Increase the maximum Image size from 23 MB to 26 MB by moving the
initramfs start address up. This gives us a bigger ranger to
provide kernel images which are not stripped down too much.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Enable ENV_IS_IN_SPI_FLASH to read the environment from the SPI
flash when booting from it. The oftree, kernel and ramdisk sizes
are located in this environment and therefore required to boot
an initramfs.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Enable ENV_IS_IN_SPI_FLASH to read the environment from the SPI
flash when booting from it. The oftree, kernel and ramdisk sizes
are located in this environment and therefore required to boot
an initramfs.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
configs: am62x_a53_usbdfu: enable USB MASS Storage command
The USB0 instance of USB on AM62 SoC when configured to operate in the
Gadget mode of operation can be used to mount an MMC/SD card on the USB
Host. Hence, enable support for the USB Mass Storage (ums) command.
Since this config fragment corresponds to USB DFU functionality which
configures the USB Controller in Gadget mode of operation, other SoCs
which include this fragment for DFU functionality can make use of the
USB MASS Storage functionality as well.
configs: j722s_evm_a53_defconfig: enable USB DFU support
The USB0 instance of USB on J722S SoC is a Designware USB Controller with
the same glue layer (wrapper) as AM62 SoC. In order to support USB DFU boot
and USB DFU flash with USB0, enable the corresponding glue layer driver.
configs: am62px_evm_a53_defconfig: enable USB DFU support
The config fragment "am62x_a53_usbdfu.config" which adds USB DFU support
for AM62x SoC is applicable to the AM62Px SoC as well. Hence, include it
in "am62px_evm_a53_defconfig" in order to enable support for USB DFU
flash and boot. Remove those configs from "am62px_evm_a53_defconfig" which
are present in the "am62x_a53_usbdfu.config" config fragment that is being
included.
board: ti: am62px: env: include environment for DFU Boot
Include the TI K3 DFU environment to support DFU Boot and DFU Flash.
Also add "usb" to the list of "boot_targets". While at it, add a newline
at the end of the file.
configs: am62ax_evm_a53_defconfig: enable USB DFU support
The config fragment "am62x_a53_usbdfu.config" which adds USB DFU support
for AM62x SoC is applicable to the AM62Ax SoC as well. Hence, include it
in "am62ax_evm_a53_defconfig" in order to enable support for USB DFU flash
and boot.
* create a parent device for all EFI block devices
* move lmb_map_update_notify() to EFI
* make efi_add_memory_map_pg() static
* remove comparisons to string literals from runtime
* ix potential deref-after-null
Other:
* avoid superfluous value check in lmb_map_update_notify()
* support more efi protocols in uuid_guid_get_str()
Please pull the fixes for rockchip platform:
- Fix for rk3399 bob and kevin
- Fix for sdram more than 4GB
- Fix for dwc_eth on rk356x/rk3588
- Fix for sdmmc access on rk33080rock-s9
When building with qemu_arm64_defconfig with CONFIG_CC_OPTIMIZE_FOR_DEBUG=y
and CONFIG_EFI_LOADER=n an error undefined reference to efi_add_memory_map_pg
occurs.
Move the EFI dependent part of lmb_map_update_notify() to the EFI
sub-system.
Reported-by: Liya Huang <1425075683@qq.com> Acked-by: Liya Huang <1425075683@qq.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
efi_driver: create a parent device for all EFI block devices
Up to now root has been the parent device for all block devices created via
calling ConnectController(). This does not work well together with the
implementation of bootstd.
Add a dummy parent device for all EFI block devices.
With this change EFI block devices are also accessible via commands like
'cat', 'load', and 'ls'.
Ilias Apalodimas [Fri, 14 Feb 2025 13:46:45 +0000 (15:46 +0200)]
efi_loader: remove comparisons to string literals from runtime
For EFI runtime services, we manage to preserve string literals
by placing the .efi_runtime section just before .data and preserving
it when marking the runtime memory by marking surrounding boottime
code as runtime. This is ok for now but will break if we update any
linker scripts and decouple .text and .runtime sections.
So let's define the strings we used to compare in the appropriate
section for runtime services
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Tom Rini [Thu, 20 Feb 2025 00:49:47 +0000 (18:49 -0600)]
Merge patch series "bloblist: refactor xferlist and bloblist"
Tom Rini <trini@konsulko.com> says:
This small series separates "bloblist" and "standard passage" to allow
for these similar concepts to explore solutions to problems without
introduces breaking changes to the other.
Raymond Mao [Thu, 20 Feb 2025 00:02:20 +0000 (16:02 -0800)]
bloblist: kconfig for mandatory incoming standard passage
In previous commit, incoming standard passage is used by default
when initializing the bloblist, so explicitly BLOBLIST_PASSAGE is
no more needed.
Rename it as BLOBLIST_PASSAGE_MANDATORY to determine the behaviors
when an incoming transfer list does not exist or is invalid.
When it is selected, incoming standard passage is mandatory and
U-Boot will report an error when a valid incoming transfer list is
missing.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Raymond Mao [Thu, 20 Feb 2025 00:02:19 +0000 (16:02 -0800)]
bloblist: refactor xferlist and bloblist
Refactor the xferlist to remove the relocating when bloblist passed
from the boot args.
Refactor bloblist init to use incoming standard passage by default
if a valid transfer list exists in the boot args.
For bloblist relocation, use the actual total size if it has a smaller
BLOBLIST_SIZE_RELOC.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org> Suggested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Jonas Karlman [Tue, 4 Feb 2025 21:38:43 +0000 (21:38 +0000)]
arm64: dts: rockchip: Fix sdmmc access on rk3308-rock-s0 v1.1 boards
BootROM leave GPIO4_D6 configured as SDMMC_PWREN function and DW MCI
driver set PRWEN high on MMC_POWER_UP and low on MMC_POWER_OFF.
Similarly U-Boot also set PRWEN high before accessing mmc.
However, HW revision prior to v1.2 must pull GPIO4_D6 low to access
sdmmc. For HW revision v1.2 the state of GPIO4_D6 has no impact.
Model an always-on active low fixed regulator using GPIO4_D6 to fix
use of sdmmc on older HW revisions of the board.
Jonas Karlman [Sun, 9 Feb 2025 23:27:56 +0000 (23:27 +0000)]
net: dwc_eth_qos_rockchip: Fix disable of RX/TX delay for RK3588
When rgmii-rxid/txid/id phy-mode is used the MAC should not add RX
and/or TX delay. Currently RX/TX delay is configured as enabled using
zero as delay value for the rgmii-rxid/txid/id modes.
Change to disable RX and/or TX delay and using zero as delay value.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Sun, 9 Feb 2025 23:27:55 +0000 (23:27 +0000)]
net: dwc_eth_qos_rockchip: Fix disable of RX/TX delay for RK356x
When rgmii-rxid/txid/id phy-mode is used the MAC should not add RX
and/or TX delay. Currently RX/TX delay is configured as enabled using
zero as delay value for the rgmii-rxid/txid/id modes.
Change to disable RX and/or TX delay and using zero as delay value.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Mon, 6 Jan 2025 21:39:42 +0000 (21:39 +0000)]
pinctrl: rockchip: rk3328: Fix pinmux for GPIO2-B and GPIO3-B pins
The pinmux bits for GPIO2-B0 to GPIO2-B6 actually have 2 bits width,
correct the bank flag for GPIO2-B. The pinmux bits for GPIO2-B7 is
recalculated so it remain unchanged. Add missing GPIO3-B1 to GPIO3-B7
pinmux data to rk3328_mux_recalced_data as mux register offset for these
pins does not follow rockchip convention.
This matches changes in following Linux commits:
- e8448a6c817c ("pinctrl: rockchip: fix pinmux bits for RK3328 GPIO2-B pins")
- 5ef6914e0bf5 ("pinctrl: rockchip: fix pinmux bits for RK3328 GPIO3-B pins")
- 128f71fe014f ("pinctrl: rockchip: correct RK3328 iomux width flag for GPIO2-B pins")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Sun, 12 Jan 2025 22:27:29 +0000 (22:27 +0000)]
rockchip: rk3288: Use rk3288-cru.h from dts/upstream
clock/rk3288-cru.h in include/dt-bindings is almost identical to the
version in dts/upstream, remove the copy from include/dt-bindings to
only use the version from dts/upstream.
One clk, SCLK_MAC_PLL, is not part of the upstream bindings, this clk is
not used by upstream, in-tree or vendor DTs and can safely be dropped.
No functional change to board DTs is intended with this removal.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Thu, 30 Jan 2025 22:07:11 +0000 (22:07 +0000)]
rockchip: sdram: Allow the first bank to extend beyond 4 GiB
Allow the first bank to extend beyond 4 GiB when the blob of space for
peripheral is located before start of DRAM, e.g. when start of DRAM
is 0x40000000 and continue beyond the 4 GiB mark.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add the dram_init_banksize function to the board file to properly set
DRAM memory sizes during boot.
The commit bc07851897bd ("board: ti: Pull redundant DDR functions to a
common location and Fixup DDR size when ECC is enabled") relocated the
dram_init_banksize function from architecture specific initialization to
the TI board initialization code. As a result, boards relying on the
previous setup now require this function to be defined within their
board file to handle DRAM sizing correctly.
Without this function defined the following error appears during boot:
ERROR: Failed to allocate 0x1000 bytes below 0x0.
Fixes: bc07851897bd ("board: ti: Pull redundant DDR functions to a common location and Fixup DDR size when ECC is enabled") Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Add the dram_init_banksize function to the board file to properly set
DRAM memory sizes during boot.
The commit bc07851897bd ("board: ti: Pull redundant DDR functions to a
common location and Fixup DDR size when ECC is enabled") relocated the
dram_init_banksize function from architecture specific initialization to
the TI board initialization code. As a result, boards relying on the
previous setup now require this function to be defined within their
board file to handle DRAM sizing correctly.
Without this function defined the following error appears during boot:
ERROR: Failed to allocate 0x1000 bytes below 0x0.
Fixes: bc07851897bd ("board: ti: Pull redundant DDR functions to a common location and Fixup DDR size when ECC is enabled") Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
The PRNG implementing the random() function only has 2^31 states and
therefore is unsafe to use for cryptography. Use arc4random() instead.
Fixes: cc34f04efd63 ("tools: image-host.c: use random instead of rand")
Addresses-Coverity-ID: 312953 Calling risky function Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Udit Kumar [Tue, 11 Feb 2025 17:51:58 +0000 (23:21 +0530)]
power: regulator: tps65941: Fix voltage calculation for ldo
As per TRM[0] Section 8.7.1 "TPS6594-Q1 Registers", LDOx_Vout
bit 6-1, define the NVM voltage settings.
Along side table 8-4 of above TRM, shows voltage to value mapping.
Driver wrongly using bits 5-1 to calculate voltage, and to convert
voltage to value driver was using buck's calculation.
So fix those calculation.
Fixes: 5d7dbd22cf7d ("power: regulator: tps65941: use function callbacks for conversion ops") Signed-off-by: Udit Kumar <u-kumar1@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Tom Rini [Tue, 18 Feb 2025 13:59:59 +0000 (07:59 -0600)]
Merge tag 'u-boot-at91-2025.07-a' of https://source.denx.de/u-boot/custodians/u-boot-at91 into next
First set of u-boot-at91 features for the 2025.07 cycle:
This feature set includes improvements on the atmel-quadspi driver, a
fix for the nand driver, and improvements on the pinctrl driver to be
able to use the Linux DT (also sync on the DT side as well).
Tom Rini [Sun, 16 Feb 2025 16:29:03 +0000 (10:29 -0600)]
Gitlab: Add missing symlink for qemu_arm64_lwip boardenv file
When adding the symlink for the conf file so qemu_arm64_lwip uses
qemu_arm64 configuration information, the symlink for the boardenv file
was missed in Gitlab (but not Azure). Add that in now.
Fixes: fd10d156db3f ("CI: add qemu_arm64_lwip to the test matrix") Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> Signed-off-by: Tom Rini <trini@konsulko.com>
Svyatoslav Ryhel [Sun, 21 Jan 2024 13:37:57 +0000 (15:37 +0200)]
board: acer: picasso: add Acer Iconia Tab A500 support
The Acer Iconia A500 is a tablet computer designed, developed and
marketed by Acer Inc. It is powered by 1 GHz Nvidia Tegra 2 processor
and 1GB DDR2 RAM. The A500 is sold with 64 GB, although both 16 GB
and 32 GB models are available.
Tom Rini [Sat, 15 Feb 2025 21:29:20 +0000 (15:29 -0600)]
Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sh
Add empty weak assembler function armv8_switch_to_el2_prep() which is
jumped to just before U-Boot determines which EL it is running in and
decides which path to take to boot the Linux kernel. Add
IH_TYPE_TFA_BL31 into supported images type, to allow implementation of
board specific U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_TFA_BL31, ...) TFA
BL31 loadable handler for fitImages.
This PR contains common hooks which are noop, R-Car Gen4 board specific
implementation using these hooks is coming in next PR.
Marek Vasut [Wed, 29 Jan 2025 21:59:19 +0000 (22:59 +0100)]
image: Add support for starting TFA BL31 as fitImage loadables
Add support for starting TFA from U-Boot running in EL3 as part of
fitImage boot, so the user can start U-Boot in the highest privilege
level on the platform, bundle TFA, Linux, DT into a single fitImage
and boot such a bundle as a whole.
There are two main benefits of this approach. First is the ability
to run U-Boot in EL3, where it has unrestricted access to the entire
system and can act as a useful debug tool, as it was always intended
to be used. Second is the ability to easily and safely update of any
component in the fitImage, be it TFA, Linux or DT.
The boot process is similar to regular Linux with DT fitImage boot
process, except the TFA has to be bundled into the fitImage. For the
bundling instructions, see below. The TFA is started as a 'loadables'
with custom U_BOOT_FIT_LOADABLE_HANDLER and armv8_switch_to_el2_prep()
handling implemented in board code, and performing the handoff and
boot in case the TFA was loaded.
The loadables handler is optional and meant to set up any sort of
handoff structures used by the TFA BL31 or perform any other setup
that is needed by the blob. The custom armv8_switch_to_el2_prep()
has to implement the jump to TFA BL31 with return to U-Boot just
before booting the Linux kernel.
Example fitImage image and configuration section:
/dts-v1/;
/ {
description = "Linux kernel with FDT blob and TFA BL31";
images {
kernel-1 { ... };
fdt-1 { ... };
atf-1 { /* This is the TFA BL31 image */
description = "TFA BL31";
data = /incbin/("../build/plat/release/bl31.bin");
type = "tfa-bl31";
arch = "arm64";
os = "arm-trusted-firmware";
compression = "none";
load = <0x46400000>;
entry = <0x46400000>;
};
};
Marek Vasut [Wed, 29 Jan 2025 21:59:18 +0000 (22:59 +0100)]
arm64: Add late jump to kernel board hook
Add empty weak assembler function armv8_switch_to_el2_prep() which is
jumped to just before U-Boot determines which EL it is running in and
decides which path to take to boot the Linux kernel.
This weak function is meant to be used by architecture specific code
to implement jump to a firmware blob, which then returns right past
this weak function and continues execution of U-Boot code which then
boots the Linux kernel. One example of such use case is when U-Boot
jump tp TFA BL31, which switches from EL3 to EL2 and then returns to
U-Boot code newly running in EL2 and starts the Linux kernel.
The weak function is called with caches already disabled and DM shut
down. Any preparatory work or even loading of more data must be done
in board_prep_linux(), this hook is meant only for the final jump to
the firmware and return to U-Boot before booting Linux.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Hironori KIKUCHI [Fri, 31 Jan 2025 01:38:41 +0000 (10:38 +0900)]
spi: soft_spi: Add support for SPI_3WIRE
When 3-wire mode is claimed on the bus, use the MOSI (output) pin to
receive data. In this mode, since the transfer can only be either TX
or RX, return -EINVAL if both are required at the same time.
Tom Rini [Fri, 14 Feb 2025 23:11:37 +0000 (17:11 -0600)]
Merge patch series "Rework requirements.txt files"
Tom Rini <trini@konsulko.com> says:
A challenge we've run in to is making it easier for more people to use
various python tools that we include in the tree. Part of the problem is
that when we have a requirements.txt file, aside from the doc one we
share with the kernel, I created it using "pip freeze". And while this
might have been a best (or at least OK) practice at the time, that's no
longer the case and is why our files have so many things in them. What
this series does is create multiple files, one per project/tool and then
has CI install them as needed. There's a few places here where this
means that we update the requirements as well, but we keep a few big
things where they are currently. This is because updating them
introduces problems of their own and delaing with that would best be a
follow up series. I've put this through GitLab and Azure to make sure
everything is still going fine on both platforms.
Tom Rini [Tue, 4 Feb 2025 23:12:09 +0000 (17:12 -0600)]
Dockerfile: Update for having more requirements.txt files
Now that we have more requirements.txt files we need to grab all of them
for creating our cache. Also, we do longer should install
python3-pyelftools on the host as it's not used.
Tom Rini [Tue, 4 Feb 2025 23:12:08 +0000 (17:12 -0600)]
python: Recreate test/py and tools/buildman requirements.txt files
Use the "pipreqs" tool to re-create these files, with a few manual
corrections. We still need to include pytest-xdist which the tool does
not detect. We also for now don't upgrade most of the required tools as
that creates problems with various tests, which should be resolved
independently.
board: ti: am62px: tifs-rm-cfg/rm-cfg: Update DMA resource sharing for CPSW
The CPSW3G instance of CPSW on AM62PX SoC provides Ethernet functionality.
Currently, Ethernet is supported on Linux which runs on the A53 core on the
SoC, by allocating all of the DMA resources associated with CPSW to A53_2.
In order to enable use-cases where the Ethernet traffic is sent from or
consumed by various CPU cores on the SoC simultaneously, while at the
same time, maintaining backward compatibility with the existing use-case
of A53 being the sole entity that exchanges traffic with CPSW via DMA,
update the DMA resource sharing scheme on AM62PX SoC to the following:
In the absence of primary owners of resources (existing use-case
where A53 owns all of the CPSW DMA resources), the secondary owner
can claim all of the resources as its own. For shared use-cases,
the resources that are not claimed by the primary are communicated
to the secondary owner allowing it to claim them. This ensures that
Linux on A53_2 can continue claiming all DMA resources associated
with CPSW in the absence of primary owners, while at the same time
providing users the flexibility to share CPSW DMA resources across
various CPU cores listed above if needed.
While Linux has been mentioned as the Operating System running
on A53, there is no dependency between the Operating System
running on A53 and its ability to claim the CPSW DMA resources
listed above.
projects / thirdparty / u-boot.git / log
